From:

Date:

August 29, 2000 15:54Subject:

Re: Proposed RFC for matrix indexing and slicingMessage ID:

00cd01c0120c$16534f80$0100a8c0@optimaldecisions.comThis RFC is a good start. Here's some thoughts on ways to decrease the amount of new syntax and avoid the HOF ambiguity... Also, I suggest multiple RFCs for the different ideas contained within. Buddha Buck wrote: > I propose the use of ';' as a separator for index terms when accessing > multi-dimensional arrays (matrices). The syntax > "$matrix[$w;$x;$y;$z];" is clearer and more flexible than other > proposed alternatives. The flexibility is mainly in the possibility > of a robust slicing syntax. > I prefer the syntax I suggested yesterday: $a[[$i,$j,$k]]; which also allows multiple elements: $a[[$i,$j,$k], [$x,$y,$z]]; Since this would just be syntactic sugar over a list ref of list refs (under my proposal yesterday), you could also say: $a[$i][$j][$k]; In addition, I would like to see multiple elements be accessible in this way: $a[$i,$x][$j,$y][$k,$z]; # == $a[[$i,$j,$k], [$x,$y,$z]]; > Although I know of no RFC's that recommend the implementation of > matrices, I expect such a proposal to be made, and this RFC does not > make such a suggestion. > I want to nut out the list of lists proposal I suggested yesterday on the list further before I submit an RFC on this. > $matrix[$x][$y][$z] # aka "(Lo)*L" notation ( (lists of)* lists) > $matrix[$x,$y,$z] # aka "[,,]" notation > $matrix{"$x,$y,$z"} # aka hash notation > > All three of these have problems. The (Lo)*L notation either requires > matrices be (lists of)* lists, or uses the same syntax for both > matrices and (lists of)* lists. The hash notation has the same > confusion, but with hashes. The [,,] notation is too similar to > the existing syntax for array slices. > > None of them allow for convenient matrix slicing. > Not true. If we allow: $a[$i,$x][$j,$y][$k,$z]; then matrix slicing is simple. We just use generated lists (RFC 81) to create the slices we need: $a[1..10:2][1..5]; # Stepped diagonal Furthermore, if we get RFC 24 (infinite lists) up, slices across a dimension are easy to: $a[0..][1]; # Column 2 of matrix We can also use the list-ref-as-index notation: $a[[$i,$j,$k], [$x,$y,$z]]; with functions that generate lists of list refs to slice matrices: @3d_diag_slice = partition(3, zip(1.., 1.., 1..)); # ([1,1,1],[2,2,2],[3,3,3],...) $a_diag = $a[@3d_diag_slice]; > # Use ^var to get more complicated slices > @diagonal = @matrix[^i;^i]; > @rdiagonal = @matrix[^i;$n-$i]; > @uptriangle = @matrix[^i;0..$i]; > @lowtriangle = @matrix[^i;$i..$#]; > > # These would be nice, but probably not feasable > > @trans[^i;^j] = @matrix[^j;^i]; > @tensor3[^i;^j;^k;^l] = @tensor1[^i;^j] * @tensor2[^k;^l]; > $dotproduct = reduce ^1+^2 , 0, a[^_] * b[^_]; > Named iterators are an important goal. Possibly they should have their own RFC. We should certainly stay away from the HOF notation '^', however. I think we just need a single parameter that contains the current (implicit) loop number. Maybe we can steal the deprecated '$*', only make it an array with each item being the loop number for that dimension: @trans[[$*[1], $*[0]]] = @mat; @uptriangle = @matrix[0..; 0..$*[0]]; > I'd propose that, analogous to the $#array notation for revealing the > upper index of @array, @#matrix return the analogous list: > Sounds good. > > =head2 Unresolved issue -- variable dimensionality > > Right now, the syntax above hardcodes the dimension of a matrix in the > index list. This does not allow you to write programs which > manipulate $n-dimensional matrices, where $n is computed at run-time. > This is unfortunate, and I'd like to hear suggestions on how to deal > with that issue. > The list of list ref approach would allow this easily.Thread Previous | Thread Next

- Proposed RFC for matrix indexing and slicing by Buddha Buck
**Re: Proposed RFC for matrix indexing and slicing**by Jeremy Howard- Re: Proposed RFC for matrix indexing and slicing by Buddha Buck
- Re: Proposed RFC for matrix indexing and slicing by David L. Nicol
- Re: Proposed RFC for matrix indexing and slicing by Nathan Wiger
- Re: Proposed RFC for matrix indexing and slicing by Jeremy Howard
- Re: Proposed RFC for matrix indexing and slicing by Dan Sugalski
- Re: Proposed RFC for matrix indexing and slicing by Dan Sugalski
- Re: Access to the perl6 parser by Damian Conway
- Re: Access to the perl6 parser by Damian Conway
- Re: Access to the perl6 parser by Damian Conway
- Re: Access to the perl6 parser by Dan Sugalski
- Re: Access to the perl6 parser by Christian Soeller
- Re: Proposed RFC for matrix indexing and slicing by Christian Soeller
- Re: Proposed RFC for matrix indexing and slicing by Karl Glazebrook
- Re: Proposed RFC for matrix indexing and slicing by Dan Sugalski
- Re: Proposed RFC for matrix indexing and slicing by Nathan Torkington
- Re: Proposed RFC for matrix indexing and slicing by Dan Sugalski
- Re: Proposed RFC for matrix indexing and slicing by Jeremy Howard
- Re: Proposed RFC for matrix indexing and slicing by Karl Glazebrook
- Re: Proposed RFC for matrix indexing and slicing by Bart Lateur
- Re: Proposed RFC for matrix indexing and slicing by c.soeller
- Re: Proposed RFC for matrix indexing and slicing by Karl Glazebrook
- Re: Access to the perl6 parser by Dan Sugalski
- Re: Access to the perl6 parser by Dan Sugalski
- Re: Access to the perl6 parser by Christian Soeller
- Re: Access to the perl6 parser by Jim Edwards
- Re: Access to the perl6 parser by Jim Edwards
- Access to the perl6 parser by Jim Edwards
- Re: Proposed RFC for matrix indexing and slicing by Karl Glazebrook
- Re: Proposed RFC for matrix indexing and slicing by Karl Glazebrook
- Re: Proposed RFC for matrix indexing and slicing by Buddha Buck

nntp.perl.org: Perl Programming lists via nntp and http.

Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About