develooper Front page | | Postings from August 2000

Re: Proposed RFC for matrix indexing and slicing

Thread Previous | Thread Next
Jeremy Howard
August 29, 2000 15:54
Re: Proposed RFC for matrix indexing and slicing
Message ID:
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.

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:


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:


In addition, I would like to see multiple elements be accessible in this

  $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:


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 Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About