From:

Date:

August 29, 2000 18:13Subject:

Re: Proposed RFC for matrix indexing and slicingMessage ID:

20000830011341.56C2115789@zaphodBoy, there are a lot of people on that CC: list... Anyone want off this ride? Jeremy Howard said: > This 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. New syntax isn't a problem for me, as long as: 1) It's unambiguous 2) It's easy to parse 3) It's perlish (and no, this doesn't contradict 1 and 2) How would you recommend the RFC breakdown? Use ";" for matrix index separator Use named iterators for matrix indices anything else? > > 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]]; Hmmm... This is using an anonymous array ref as an index into an array to me... Do you think you should be able to do: sub getmouseposition () { my ($x,$y) = ( $mouse->getx(), $mouse->gety() ); return ($x, $y); } $point = [ getmouseposition() ]; # returns ($x,$y) $a[$point] = $color; > which also allows multiple elements: > > $a[[$i,$j,$k], [$x,$y,$z]]; Noting the later correction to @a... This would be analogous to the perl5 slice @a[2,5]? Or would it return more than two elements? If this is right, that there is a hole in my proposal... I don't have a way to take that sort of slice. Hmmm... Could we combine the two? Given the matrix [[a,b,c], [i,j,k], [x,y,z]] $a[1;1] is equivilant to $a[[1;1]] and evaluates to j. @a[1,2;1,2] has no simple [[]] equivilant and evaluates to [[j,k],[y,z]] @a[[1;2],[1;2]] has no simple [;] equivilant and evaluates to (y,y) > Since this would just be syntactic sugar over a list ref of list refs (under > my proposal yesterday), you could also say: Let's just say that I would prefer the syntax be implementation-independ ent. lists of lists are not necessarily the best way to do this, and I'd rather that the -internals folks didn't have their hands tied because the syntax demands a particular implementation. My proposal would work just as well over an internal lists of lists representation as it would over others. > $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]]; $a[$i,$x][$j,$y][$k,$z] already can be used as an lvalue. I'm not entirely sure what it does, but it works. I would guess that it's the same as $a[$x][$y][$z], which is not what you want. How do you distinguish the two cases? > > 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 First, shouldn't that be @a[1..10:2][1..5], and that will give elements (1,1),(3,2),(5,3),(7,4),(9,5), right? Like @a[2*^i-1;^i]? > > 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]; Shouldn't that be @a_diag = @a...? > > > # 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: That's stealing @*, not $*. I don't know if @* is in use. > > @trans[[$*[1], $*[0]]] = @mat; > @uptriangle = @matrix[0..; 0..$*[0]]; This may be nice... I couldn't figure out how to do the 3-dim analog to @uptriangle, but it would work as: @uptetra = @cube[0..;0..$*[0];0..$*[1]]; (I think) > > 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. Yes it would, but that's an implementation detail, not a syntactic one. Again, I'd like to separate syntax issues from implementation issues -- or at least, not have syntax bind the implementors. -- Buddha Buck bmbuck@14850.com "Just as the strength of the Internet is chaos, so the strength of our liberty depends upon the chaos and cacophony of the unfettered speech the First Amendment protects." -- A.L.A. v. U.S. Dept. of JusticeThread 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