<Cross-posted from internals to language since some language issues are
cropping up>
Ken Fox wrote:
> > $a = sum(@b*@c+@d)
>
> I'm not strong in math, but I do remember a bit about row and column
> vectors. Isn't @b*@c ambiguous? Shouldn't it normally be interpreted
> as a dot product, i.e. treat all vectors the same?
>
It depends on what perl6-language comes up with. Probably '*' will mean
component-wise product and 'x' will mean inner product (or visa-versa). I'm
talking about the component-wise product version.
> > The normal problem with this type of structure is that the previous
> > statement would create 2 array copies, and 3 loops for most compilers.
In
> > perl speak, it might look like:
> > $dummy1[$_] = $b[$_]*$c[$_] for (0..$#b-1);
> > $dummy2[$_] = $d[$_]+$dummy1[$_] for (0..$#dummy1-1);
> > $sum+=$_ for (@dummy2);
>
> A simpler rule would be to treat an array as an implicit stream
> whenever it's used in a scalar+reduce context. Then the following
> code would be generated:
>
> $dummy1 = stream @b;
> $dummy2 = stream @c;
> $dummy3 = stream @d;
> while ($dummy4 = $dummy1->next * $dummy2->next + $dummy3->next) {
> $sum += $dummy4;
> }
>
Excellent! There are C++ libraries that use the stream approach, and they're
_really_ fast! But they're a pain to use. This is just the kind of extra
optimisation I was hoping that perl 6 could achieve.
> > $sum+=$b[$_]*$c[$_]+$d[$_] for (0..$#b-1);
>
> Shouldn't that be
>
> $sum+=$b[$_]*$c[$_]+$d[$_] for (0..min($#b, $#c, $#d));
>
Actually, we're still trying to decide on perl6-language what this means. It
might be even be max(), with undef passed in for short arrays. I was just
being lazy to show an example.
> > Without this optimisation, array semantics become next to useless for
> > numeric programming, because their overhead is just so high.
>
> I think talking about array semantics instead of vector and matrix
> semantics is next to useless too, but I'm not a math guy.
>
I really mean 'tensor semantics', which is a generalisation of matrices to n
dimensions. But I was worried that non-math guys might see 'tensor' and
their brains would explode ;-)
Anyway, tensors are just a generalisation. Ideally, good slicing, masking,
and indirect indexing on arrays allow the user to easily create any kind of
multi-dimensional structure they want, including sparse structures. Then
it's just a case of creating wrappers to make them look like real tensors.
...As long as the overhead is stripped away at compile time, of course.
