develooper Front page | perl.perl6.language | Postings from January 2004

Re: Semantics of vector operations

Thread Previous | Thread Next
Luke Palmer
January 22, 2004 13:28
Re: Semantics of vector operations
Message ID:
Austin Hastings writes:
> How do you handle operator precedence/associativity?
> That is,
>    $a + $b + $c
> If you're going to vectorize, and combine, then you'll want to group. I
> think making the vectorizer a grouper as well kills two birds with one
> stone.
>   $a + >>$b + $c<<
> vs.
>   $a +<< ($b + $c)

I have to agree with Larry here, the latter is much cleaner.

I'm actually starting to like this proposal.  I used to shiver at the
implementation of the old way, where people used the operator to group
arbitrary parts of the expression.  I wouldn't even know how to parse
that, much less interpret it when it's parsed.

Now, we have a clear way to call a method on a list of values:

    @list ».method

And a clear way to call a list of methods on a value:

    $value.« @methods

It's turning out pretty nice.

> > You might argue that we should force people to think of it one way or
> > the other.  But there's a reason that some people will think of it
> > one way while others will think of it the other way--I'd argue that
> > vectorization is not something that happens to *either* the operand
> > or the operator.  Vectorization is a different *relationship* between
> > the operator and the operand.  As such, I still think it belongs
> > between.
> >
> > Plus, in the symmetrical case, it *looks* symmetrical.  Marking the
> > args in front makes everything look asymmetrical whether it is or not.
> Just a refresher, what *exactly* does vectorization do, again?  I think of
> it as smart list-plus-times behavior, but when we go into matrix arithmetic,
> that doesn't hold up. Luke?

Well, for being called "vector operators", they're ending up pretty
useless as far as working with mathematical vectors.  As a
mathematician, I'd want:

    @vec1 »*« @vec2

To do an inner or an outer product (probably outer, as it has no
implicit connotations of the + operator).  That is, it would come out
either a matrix or a scalar.

But there are other times when I'd want that to call the operator
respectively.  Then you get this for the inner product:

    sum(@vec1 »*« @vec2)

Which isn't so bad, after all.

Hmm, but if it does give an outer product, then a generic tensor product
is as easy as:

    reduce { $^a »+« $^b } @A »*« @B

And nobody can fathom how happy that would make me.

Also, you'd get the nice consistency that:

    @A »+« @B

Is the same as both:

    map { @A »+ $^b } @B
    map { $^a +« @B } @A

Which is undoubtedly what the mathematician would expect  (It's very
reminiscent of how junctions currently work).

But then there's the problem of how you express the oft-wanted:

    map -> $i { @A[$i] + @B[$i] } 0..^min(+@A, +@B)

(Hopefully when @A and @B are of equal length).

Maybe there's a way to do it so that we can both be happy: one syntax
that does one thing, another that does the other.  Like:

    @A »+« @B           # One-at-a-time
    @A «+» @B           # Outer product

Or something.  Hmm, then both:

    @A »+ $b
    @A «+ $b

Would mean the same thing. 


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