Buddha Buck wrote:
> I think that once you have LOL's automagically padded to size, and that
> size stored as an intrinsic part of the LOL, you no longer have a
> traditional LOL. You have something that looks, walks, and quacks like
> a matrix and doesn't walk or quack like an LOL. Why not call it a
> matrix?
>
Sure--I'll call it a matrix. It doesn't change the syntax or implementation
though.
> I -like- the idea of array refs being used as indices into matrices.
> It's a natural extension to the existing array notation. I -don't-
> like the idea of LOL notation for matrix access -- especially if you
> don't plan on actually implementing matrices as LOLs.
You say tomayto, I say tomarto.
Under the revised proposal from Christian and I, you can have both.
> If LOLs were
> sufficient for matrix implimentation, PDL would not have done what they
> did.
>
P5 LOLs are not sufficient for matrix implementation, and not scalable
enough to add it in. That says nothing about P6 LOLs.
> Which is more important, the fundamentals of n-dim array operation, or
> reduce on n-dim arrays? If the former, optimise n-dim arrays for the
> fundamentals, which may not lead to LOL as the solution. If the
> latter, then LOL's may be the way to go. Or maybe not...
>
We're talking about syntax, not implementation. Supporting LOL syntax
(amongst others) does not impact what we optimise. What it does do, however,
is allow us to avoid rewriting every function that acts on a list so that it
also works with our new notation, because we will _also_ support the LOL
notation that functions understand.
> @xsums[^i;^j] = reduce sum 0,@cube[..;^i;^j];
> @ysums[^i;^j] = reduce sum 0,@cube[^i;..;^j];
> @zsums[^i;^j] = reduce sum 0,@cube[^i;^j;..];
>
> How would that go in LOL notation?
Let's stick to the reduce() that is already proposed in RFC 76. If you want
a different version, propose it so that we can discuss it. Under RFC 76 it
would be:
sub sum (@) { reduce ^_ + ^_, @_; }
Applying sum() then to a matrix/LOL would require some kind of magic
iterator:
@xsums[[ $*[1], [$*[2] ]] = sum(@cube[0..; $*[1]; $*[2]);
This assumes the magic '@*' variable we've discussed that creates an
implicit loop across each dimension that appears as a subscript to @*.
There's lots of issues around this to be resolved still ...how do we specify
we want to loop over a subset of a dimension? ...how do we avoid the
overhead of all those function calls?
You'll see that I'm using the ';' operator as a list generator here to
create a cartesian product, as Christian and I discussed earlier--it results
in the exact same notation as Buddha's n-dim indexing.
