Boy, 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 [EMAIL PROTECTED]
"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 Justice
