develooper Front page | | Postings from August 2000

Re: Proposed RFC for matrix indexing and slicing

Thread Previous | Thread Next
Buddha Buck
August 29, 2000 18:13
Re: Proposed RFC for matrix indexing and slicing
Message ID:
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[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                   
"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

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About