hyperoperators and multi-dimensional datastructures
Anthony Heading
multi-dimensional array? This is an attractive feature of
various APL-like languages, viz. e.g. in J:
a =. 2 5 $ i. 7 - a simple 2-by-5 array
a
0 1 2 3 4 - like this
5 6 0 1 2
+/"1 a - sum reduce over axis 1
10 14
+/"2 a - sum reduce over axis 2
5 7 2 4 6
Anthony
Luke Palmer
> Is there a way to target hyperoperators at different axes of a
> multi-dimensional array? This is an attractive feature of
> various APL-like languages, viz. e.g. in J:
>
> a =. 2 5 $ i. 7 - a simple 2-by-5 array
> a
> 0 1 2 3 4 - like this
> 5 6 0 1 2
>
>
> +/"1 a - sum reduce over axis 1
> 10 14
[+]<< @a
> +/"2 a - sum reduce over axis 2
> 5 7 2 4 6
Can't think of any for this one. Or maybe it's this one that I can
think of it for, and the other one which I can't.
I think we're beginning to re-invent PDL. Poorly.
Luke
Uri Guttman
LP> On 5/18/05, Anthony Heading <aj...@ajrh.net> wrote:
>> Is there a way to target hyperoperators at different axes of a
>> multi-dimensional array? This is an attractive feature of
>> various APL-like languages, viz. e.g. in J:
>>
>> a =. 2 5 $ i. 7 - a simple 2-by-5 array
>> a
>> 0 1 2 3 4 - like this
>> 5 6 0 1 2
>>
>>
>> +/"1 a - sum reduce over axis 1
>> 10 14
LP> [+]<< @a
>> +/"2 a - sum reduce over axis 2
>> 5 7 2 4 6
LP> Can't think of any for this one. Or maybe it's this one that I can
LP> think of it for, and the other one which I can't.
i can't spit out the syntax but here is the conceptual way i would do
it. we do have multidimensional slices so we could grab each slice
(maybe with zip?) and pass that to [+] and then grab the list of results
back into a array/matrix with one less dimension than the original.
so it would be something like this: (very wacko pseudo code):
@in[ * ; 2 ; * ] ==>
map [+] ==>
@out
that was an (bad) attempt to slice the third entry in the second
dimension to be summed.
LP> I think we're beginning to re-invent PDL. Poorly.
but is there a p6 pdl yet? they may not need much with multi-dim ops,
slices, hyper and reduce all built in! also with type int (patform
ints), they can get the dense storage needed (but losing any dimensional
flexibility).
uri
--
Uri Guttman ------ u...@stemsystems.com -------- http://www.stemsystems.com
--Perl Consulting, Stem Development, Systems Architecture, Design and Coding-
Search or Offer Perl Jobs ---------------------------- http://jobs.perl.org
Anthony Heading
> i can't spit out the syntax but here is the conceptual way i would do
> it. we do have multidimensional slices so we could grab each slice
> (maybe with zip?) and pass that to [+] and then grab the list of results
> back into a array/matrix with one less dimension than the original.
Yup. I wonder though if that formulation is made simpler by
the notion of iterating a data structure at a given
depth. It might even be useful for $data{$x}{$y}{$z}[$i] or
similar, where e.g. map() could make a deep copy down to a
certain depth where it then operates elementwise.
> so it would be something like this: (very wacko pseudo code):
>
> @in[ * ; 2 ; * ] ==>
> map [+] ==>
> @out
>
One limiting thing about this is that the data being 3-dimensional
and the focus on the second dimension are explicit in the syntax:
presumably not possible to reduce a $j dimensional array over
dimension $i in the same way. Equivalently, the autoindexing described
in Synopsis 9 looks like it enables
do -> $i, $j, $k { @sum[$i, $k] = @data[$i, $j, $k] }
which is very elegant. But if I was wanting to write a library
which handles arbitrary data "cubes", it would be nice to specify
the dimensions using variables.
> LP> I think we're beginning to re-invent PDL. Poorly.
>
> but is there a p6 pdl yet? they may not need much with multi-dim ops,
> slices, hyper and reduce all built in! also with type int (patform
> ints), they can get the dense storage needed (but losing any dimensional
> flexibility).
Yes. I don't quite understand that point. I rather see PDL as a limited
version of MATLAB, and MATLAB as a limited version of APL. The right
set of vector primitives can be combined powerfully in some very
non-obvious ways (c.f. in fact the recent post by Edward Cherlin), and
APL and successors have worked this out over 30+ years. To hold PDL as
a design benchmark instead doesn't seem quite right.
Rgds
Anthony
Edward Cherlin
> >>>>> "LP" == Luke Palmer <lrpa...@gmail.com> writes:
>
> LP> On 5/18/05, Anthony Heading <aj...@ajrh.net> wrote:
> >> Is there a way to target hyperoperators at different axes
> >> of a multi-dimensional array? This is an attractive
> >> feature of various APL-like languages, viz. e.g. in J:
> >>
> >> a =. 2 5 $ i. 7 - a simple 2-by-5 array
> >> a
> >> 0 1 2 3 4 - like this
> >> 5 6 0 1 2
> >>
> >>
> >> +/"1 a - sum reduce over axis 1
> >> 10 14
That is, break the array into rows, and reduce each row.
> LP> [+]<< @a
>
> >> +/"2 a - sum reduce over axis 2
> >> 5 7 2 4 6
Actually, that's sum reduce over planes, which gives the default
behavior when applied to a single plane, of breaking the plane
into rows, and adding the rows to each other. The result is the
same as from +/a .
The rank conjunction (") is tersely explained at
http://www.jsoftware.com/books/help/dictionary/intro20.htm
and more fully in The J Primer, J for C Programmers, and other
online publications at
http://www.jsoftware.com/publications_books.htm
> LP> Can't think of any for this one. Or maybe it's this one
> that I can LP> think of it for, and the other one which I
> can't.
>
> i can't spit out the syntax but here is the conceptual way i
> would do it. we do have multidimensional slices so we could
> grab each slice (maybe with zip?) and pass that to [+] and
> then grab the list of results back into a array/matrix with
> one less dimension than the original.
Exactly how Iverson conceived rank for reduction.
> so it would be something like this: (very wacko pseudo code):
>
> @in[ * ; 2 ; * ] ==>
> map [+] ==>
> @out
>
> that was an (bad) attempt to slice the third entry in the
> second dimension to be summed.
You might find it useful to examine this published source code
for an early version of J
http://www.math.uwaterloo.ca/apl_archives/j/early_j/src/j7/
to see how Iverson's crew implemented rank.
The numbering is confusing, because they restarted at some point,
so J5.0.4 is current.
> LP> I think we're beginning to re-invent PDL.
APL and J, too.
> Poorly.
Amen.
> but is there a p6 pdl yet? they may not need much with
> multi-dim ops, slices, hyper and reduce all built in! also
> with type int (patform ints), they can get the dense storage
> needed (but losing any dimensional flexibility).
>
> uri
--
Edward Cherlin
Generalist & activist--Linux, languages, literacy and more
"A knot! Oh, do let me help to undo it!"
--Alice in Wonderland
http://cherlin.blogspot.com