Re: Semantics of vector operations
On Thu, Jan 22, 2004 at 03:53:04AM +0100, A. Pagaltzis wrote: : Good point; however, this means different way to think of the : vector ops than we had so far. Basically, we're moving from the : realm of vector ops to that of vectorized operands. : : In light of this, I think Austin's proposal of marking the : operands as vectorized makes a lot of sense. It was an unexpected : that had me taken aback for a moment, but I like it more the more : I think about it. It *feels* right to emphasize vectorization as : something that happens to an operand, rather than something : that's a property of the operation. I think some people will want to think of it one way, while others will want to think of it the other way. If that's the case, the proper place to put the marker is between the operand and the operator. 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. Larry
Re: Semantics of vector operations
On Thu, Jan 22, 2004 at 03:57:26AM +0100, A. Pagaltzis wrote: : * Piers Cawley <[EMAIL PROTECTED]> [2004-01-21 23:33]: : > And once you go to an image based IDE and have access to the : > bytecode of the code you're writing there's all *sorts* of : > interesting things you can do. And that's before one starts to : > imagine attaching the IDE/debugger to a running process... : : $smalltalkometer++ ? :) %languageometer.values »+=« rand; Not to be confused with %languageometer.values »+= rand; which would presumably add the *same* number to all languageometers. Larry
RE: Semantics of vector operations (Damian)
> -Original Message- > From: Larry Wall [mailto:[EMAIL PROTECTED] > Sent: Thursday, January 22, 2004 12:50 PM > To: Language List > Subject: Re: Semantics of vector operations > > > On Thu, Jan 22, 2004 at 03:57:26AM +0100, A. Pagaltzis wrote: > : * Piers Cawley <[EMAIL PROTECTED]> [2004-01-21 23:33]: > : > And once you go to an image based IDE and have access to the > : > bytecode of the code you're writing there's all *sorts* of > : > interesting things you can do. And that's before one starts to > : > imagine attaching the IDE/debugger to a running process... > : > : $smalltalkometer++ ? :) > > %languageometer.values »+=« rand; > > Not to be confused with > > %languageometer.values »+= rand; > > which would presumably add the *same* number to all languageometers. > In reverse order: > %languageometer.values »+= rand; This is the same as all( %languageometer.values ) += rand; right? And is this > %languageometer.values »+=« rand; the same as all( %languageometer.values ) += one( rand ); ? =Austin
RE: Semantics of vector operations
> -Original Message- > From: Larry Wall [mailto:[EMAIL PROTECTED] > Sent: Thursday, January 22, 2004 12:39 PM > To: Language List > Subject: Re: Semantics of vector operations > > > On Thu, Jan 22, 2004 at 03:53:04AM +0100, A. Pagaltzis wrote: > : Good point; however, this means different way to think of the > : vector ops than we had so far. Basically, we're moving from the > : realm of vector ops to that of vectorized operands. > : > : In light of this, I think Austin's proposal of marking the > : operands as vectorized makes a lot of sense. It was an unexpected > : that had me taken aback for a moment, but I like it more the more > : I think about it. It *feels* right to emphasize vectorization as > : something that happens to an operand, rather than something > : that's a property of the operation. > > I think some people will want to think of it one way, while others > will want to think of it the other way. If that's the case, the > proper place to put the marker is between the operand and the operator. > 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) > 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? =Austin
RE: Semantics of vector operations (Damian)
> -Original Message- > From: Jonathan Scott Duff [mailto:[EMAIL PROTECTED] > Sent: Thursday, January 22, 2004 1:16 PM > To: Austin Hastings > Cc: Larry Wall; Language List > Subject: Re: Semantics of vector operations (Damian) > > > On Thu, Jan 22, 2004 at 01:10:23PM -0500, Austin Hastings wrote: > > In reverse order: > > > > > %languageometer.values ?+= rand; > > > > This is the same as > > > > all( %languageometer.values ) += rand; > > > > right? > > It's the same as > > $r = rand; > $_ += $r for %languageometer.values > > Your junction looks like it should work but I think you're really > adding the random number to the junction, not the elements that compose > the junction thus none of %languageometer.values are modified. It would be disappointing if junctions could not be lvalues. > > And is this > > > > > %languageometer.values ?+=? rand; > > > > the same as > > > > all( %languageometer.values ) += one( rand ); > > I don't think so. It's like: > > $_ += rand for %languageometer.values > > perhaps if you had: > > $j |= rand for (0..%languageometer.values) > any(%languageometer.values) += $j; > > Though I'm not sure what that would mean. > > I don't think junctions apply at all in vectorization. They seem to > be completely orthogonal. I'm curious if that's true, of if they're two different ways of getting to the same data. (At least in the one-dimension case.) =Austin
Re: Comma Operator
On Wed, Jan 21, 2004 at 08:51:33PM -0500, Joe Gottman wrote:
: Great, so
: $x = foo(), bar();
: means the same thing as
: $x = ( foo(), bar() );
No, we haven't changed the relative precedence of assignment and comma.
I've been tempted to, but I always come back to liking the parens
for visual psychological purposes. Plus changing the precedence
would break
loop $i = 0, $j = 0; $x[$i,$j]; $i++, $j++ { ... }
: Is the optimizer going to be smart enough so that given the expression
: $x = (foo(), bar(), glarch())[-1];
:
: Perl6 won't have to construct a three-element array just to return the last
: element?
It's interesting to me that you assume there would be a three element
array there. If the ()[] works like it does in Perl 5, the stuff inside
the parens is always evaluated in list context. Which means that foo(),
bar(), and glarch() can any of them return 0 or more elements. There's
no guarantee that the final value doesn't come from foo() or bar().
Now, in Perl 6, slices are distinguished from single subscripts only by
the form of the subscript, not by any sigil. So we can know for a fact
that [-1] is not a slice. But that doesn't mean we can necessarily
assume that the list in parens wants to evaluate its args in scalar
context. Maybe it does, and maybe it doesn't.
That doesn't mean that we have to put the C comma operator back
in though. It might just mean that the default is wrong on ()[].
Suppose we say that
(foo(), bar(), glarch())[-1]
by default evaluates its arguments in scalar context. To get the Perl 5
behavior, you'd merely have to use a splat to put the list into list
context:
(* foo(), bar(), glarch())[-1]
Then (...)[] would become the standard way of producing a list of
things evaluated in scalar context. Alternately, if you don't like
the splat list, you can always say
[foo(), bar(), glarch()][-1]
which does the same thing.
Given all that, I think we can say that, yes, the compiler can
optimize foo() and bar() to know they're running in void context.
I'd generalize that to say that any unselected element of a scalar
list can be evaluated in a void context, whether the subscript is -1
or 0 or any constant slice.
Larry
Re: Semantics of vector operations (Damian)
On Thu, Jan 22, 2004 at 01:10:23PM -0500, Austin Hastings wrote: > In reverse order: > > > %languageometer.values ?+= rand; > > This is the same as > > all( %languageometer.values ) += rand; > > right? It's the same as $r = rand; $_ += $r for %languageometer.values Your junction looks like it should work but I think you're really adding the random number to the junction, not the elements that compose the junction thus none of %languageometer.values are modified. > And is this > > > %languageometer.values ?+=? rand; > > the same as > > all( %languageometer.values ) += one( rand ); I don't think so. It's like: $_ += rand for %languageometer.values perhaps if you had: $j |= rand for (0..%languageometer.values) any(%languageometer.values) += $j; Though I'm not sure what that would mean. I don't think junctions apply at all in vectorization. They seem to be completely orthogonal. -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: Semantics of vector operations
On Thu, Jan 22, 2004 at 01:10:25PM -0500, Austin Hastings wrote: : > -Original Message- : > From: Larry Wall [mailto:[EMAIL PROTECTED] : > I think some people will want to think of it one way, while others : > will want to think of it the other way. If that's the case, the : > proper place to put the marker is between the operand and the operator. : : How do you handle operator precedence/associativity? Me? I handle it by making it an adverb on the base operator. :-) : 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<< Er, pardon me, but bletch. : vs. : : $a +<< ($b + $c) That's much clearer to me. (Ignoring the fact that you can't add references. :-) : > 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? It really means "please dereference this scalar in an intelligent fashion for this particular operator". The exact behavior is allowed to depend on the operator and the types of both arguments (if both sides are vectorized). That is, it's probably a multimethod in disguise. Actually, it's a bit misleading to call it a vectorizing operator. It's really a dwim operator that will commonly be used for vectorizing in the case of one-dimensional lists. For higher dimensional beasties, it means "make these conform and then apply the operator in some kind of distributed fashion, with a bias toward leaf operations". I don't think that »X« means "Do whatever the mathematicians want X to do." Unicode operators have to be good for something, after all. So perhaps its best to call » and « "distribution modifiers" or some such. Larry
Re: Semantics of vector operations (Damian)
Jonathan Scott Duff writes: > On Thu, Jan 22, 2004 at 01:10:23PM -0500, Austin Hastings wrote: > > In reverse order: > > > > > %languageometer.values Â+= rand; > > > > This is the same as > > > > all( %languageometer.values ) += rand; > > > > right? Well, yes. It's also the same as each of: any( %languageometer.values ) += rand; none( %languageometer.values ) += rand; one( %languageometer.values ) += rand; Since the junctions aren't yet being evaluated in boolean context, the type of the junction doesn't matter. Which is why making junctions applicable lvalues might be a bad idea. I'm not sure, but this looks like a potential confuser. > It's the same as > > $r = rand; > $_ += $r for %languageometer.values > > Your junction looks like it should work but I think you're really > adding the random number to the junction, not the elements that compose > the junction thus none of %languageometer.values are modified. Hmm... that depends on whether junctions hold references, or what they do in lvalue context, and a whole bunch of other, undecided things. > > And is this > > > > > %languageometer.values Â+=Â rand; > > > > the same as > > > > all( %languageometer.values ) += one( rand ); No, what you just wrote is the same as: all( %languageometer.values ) += rand; > I don't think so. It's like: > > $_ += rand for %languageometer.values Sortof. I think Larry was implying that rand returned an infinite list of random numbers in list context. If not, then what he said was wrong, because it would be sick to say that: (1,2,3,4,5) Â+Â foo() Calls foo() 5 times. > perhaps if you had: > > $j |= rand for (0..%languageometer.values) > any(%languageometer.values) += $j; > > Though I'm not sure what that would mean. Nonononono! Don't do that! That adds *each* of the random numbers to *each* of the values. That is, each of the values would increase by approximately %languageometer/2. > I don't think junctions apply at all in vectorization. They seem to > be completely orthogonal. I'd be happy if that were the case. Luke Ã
Re: Semantics of vector operations
* Larry Wall <[EMAIL PROTECTED]> [2004-01-22 18:40]: > You might argue that we should force people to think of it one > way or the other. I wouldn't, because if I did I'd should've been talking to Guido rather than you in the first place. :-) And because I'm talking to you, I'll wonder whether maybe we ought to have both options. > 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. That makes a lot of sense; consider me convinced. Even if I agree after all though, that doesn't make me like the way »+ and particularly +« look any more than I liked them before. I usually scoff at "line noise" remarks, but in this case I'd feel forced to mutter it myself -- it just continues to feel like too big a change in behaviour dictated by a single "magic character". While »+« is a little ugly as well, it does stand out boldly, something that could not IMHO be said about the one-sided variants. I'd argue that we really should use something more visually prominent for the one-sided case. Maybe »»+ and +«« or something? But the non-Unicode variant would be, uh, less than pretty. > Plus, in the symmetrical case, it *looks* symmetrical. Marking > the args in front makes everything look asymmetrical whether it > is or not. I was actually thinking something like »$a« + »$b« in which case asymmetry would not be an issue. -- Regards, Aristotle "If you can't laugh at yourself, you don't take life seriously enough."
Re: Semantics of vector operations
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([EMAIL PROTECTED], [EMAIL PROTECTED])
(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.
Luke
Ã
RE: Semantics of vector operations (Damian)
> -Original Message-
> From: Luke Palmer [mailto:[EMAIL PROTECTED]
> Sent: Thursday, January 22, 2004 3:52 PM
> To: Austin Hastings; Larry Wall; Language List
> Subject: Re: Semantics of vector operations (Damian)
>
>
> Jonathan Scott Duff writes:
> > On Thu, Jan 22, 2004 at 01:10:23PM -0500, Austin Hastings wrote:
> > > In reverse order:
> > >
> > > > %languageometer.values Â+= rand;
> > >
> > > This is the same as
> > >
> > > all( %languageometer.values ) += rand;
> > >
> > > right?
>
> Well, yes. It's also the same as each of:
>
> any( %languageometer.values ) += rand;
> none( %languageometer.values ) += rand;
> one( %languageometer.values ) += rand;
>
> Since the junctions aren't yet being evaluated in boolean context, the
> type of the junction doesn't matter.
That is clear, once you've pointed it out, but really counterintuitive. Since all
things are applicable, though, I don't object too much -- it's like "and" vs. "but" in
English, I guess.
> Which is why making junctions applicable lvalues might be a bad idea. I'm not sure,
> but this
> looks like a potential confuser.
I think I disagree. With the caveat that there may be something to be said for
discriminating between assigning TO a junction variable and assigning THROUGH one, I
think that the presence or absence of assignment-operators is still the (obvious,
sufficient) indicator that an assignment is taking place.
all(%languageometer.values) + 6
doesn't look like (and shouldn't be) an assignment.
all(%languageometer.values) += 6;
does.
> > It's the same as
> >
> > $r = rand;
> > $_ += $r for %languageometer.values
> >
> > Your junction looks like it should work but I think you're really
> > adding the random number to the junction, not the elements that compose
> > the junction thus none of %languageometer.values are modified.
>
> Hmm... that depends on whether junctions hold references, or what they
> do in lvalue context, and a whole bunch of other, undecided things.
>
> > > And is this
> > >
> > > > %languageometer.values Â+=Â rand;
> > >
> > > the same as
> > >
> > > all( %languageometer.values ) += one( rand );
>
> No, what you just wrote is the same as:
>
> all( %languageometer.values ) += rand;
So the vectorization op is providing the "call once per element" distribution service.
Which takes vectorization out of the MTOWTDI category and into the somewhat-orthogonal
functionality category.
Vectorized operator: %languageometer.values Â+=Â rand;
Vectorized "sides": %languageometer.values Â+=Â rand;
Alt. Vectorized "sides": all(%languageometer.values) +=Â rand;
Vectorized operands: Â%languageometer.values += ÂrandÂ;
Alt. Vectorized operands: all(%languageometer.values) += ÂrandÂ;
I withdraw my aesthetic objection: if vectorizing the operator isn't going to work, I
don't like *any* of them very much.
> > I don't think so. It's like:
> >
> > $_ += rand for %languageometer.values
>
> Sortof. I think Larry was implying that rand returned an infinite list
> of random numbers in list context. If not, then what he said was wrong,
> because it would be sick to say that:
>
> (1,2,3,4,5) Â+Â foo()
>
> Calls foo() 5 times.
Why would it be sick, and in what context?
With Larry's new "vectorized sides" suggestion, putting a guillemot on the right side
of the operator vectorizes the right side operand, which *should* call foo() five
times.
(1,2,3,4,5) Â+ foo() # do { my $x=foo(); (1+$x, 2+$x, 3+$x, 4+$x, 5+$x); }
(1,2,3,4,5) Â+Â foo() # (1+foo(), 2+foo(), 3+foo(), 4+foo(), 5+foo())
(1,2,3,4,5) +Â foo() # Maybe the same as above? What does
infix:+(@list,$scalar) do?
(1,2,3,4,5) + foo() # foo() in list context? What does infix:+(@list, @list2)
do?
=Austin
Re: Semantics of vector operations (Damian)
Austin Hastings writes:
> > Sortof. I think Larry was implying that rand returned an infinite list
> > of random numbers in list context. If not, then what he said was wrong,
> > because it would be sick to say that:
> >
> > (1,2,3,4,5) Â+Â foo()
> >
> > Calls foo() 5 times.
>
> Why would it be sick, and in what context?
>
> With Larry's new "vectorized sides" suggestion, putting a guillemot on the right
> side of the operator vectorizes the right side operand, which *should* call foo()
> five times.
>
> (1,2,3,4,5) Â+ foo() # do { my $x=foo(); (1+$x, 2+$x, 3+$x, 4+$x, 5+$x); }
> (1,2,3,4,5) Â+Â foo() # (1+foo(), 2+foo(), 3+foo(), 4+foo(), 5+foo())
I think that one is:
do { my @x=foo(); ([EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL
PROTECTED], [EMAIL PROTECTED]) }
We've forgotten that foo() could return a list in list context. :-)
> (1,2,3,4,5) +Â foo() # Maybe the same as above? What does
> infix:+(@list,$scalar) do?
Well, what does a list return in scalar context? In the presence of the
C comma, it returns 5 for the last thing evaluated. In its absence, it
returns 5 for the length.
> (1,2,3,4,5) + foo() # foo() in list context? What does infix:+(@list,
> @list2) do?
Same deal, 5 + $(foo())
Luke
Ã
Re: Semantics of vector operations (Damian)
Luke Palmer writes: > > (1,2,3,4,5) +Â foo() # Maybe the same as above? What does > > infix:+(@list,$scalar) do? > > Well, what does a list return in scalar context? In the presence of the > C comma, it returns 5 for the last thing evaluated. In its absence, it > returns 5 for the length. > > > (1,2,3,4,5) + foo() # foo() in list context? What does infix:+(@list, > > @list2) do? > > Same deal, 5 + $(foo()) And of course I forgot to read you comments. So you want to add two lists, as in: [1,2,3,4,5] + [foo()] Well, that's an error, I think. That or it adds the lengths. Luke Ã
Re: Semantics of vector operations
On Thu, Jan 22, 2004 at 11:25:41AM -0800, Larry Wall wrote: > On Thu, Jan 22, 2004 at 01:10:25PM -0500, Austin Hastings wrote: > : > -Original Message- > : > From: Larry Wall [mailto:[EMAIL PROTECTED] > : > I think some people will want to think of it one way, while others > : > will want to think of it the other way. If that's the case, the > : > proper place to put the marker is between the operand and the operator. > : > : How do you handle operator precedence/associativity? > > Me? I handle it by making it an adverb on the base operator. :-) Does that mean it should get the colon? :) > I don't think that ?X? means "Do whatever the mathematicians want X > to do." Unicode operators have to be good for something, after all. > > So perhaps its best to call ? and ? "distribution modifiers" or > some such. Could someone put the non-unicode variants up there so those of us with unicode-ignorant MUAs can know what exactly we're talking about? Or alternatively (and certainly better), could someone clue me on how to make mutt unicode-aware? thanks, -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: Semantics of vector operations (Damian)
On Thu, Jan 22, 2004 at 01:28:42PM -0500, Austin Hastings wrote:
> > From: Jonathan Scott Duff [mailto:[EMAIL PROTECTED]
> > On Thu, Jan 22, 2004 at 01:10:23PM -0500, Austin Hastings wrote:
> > > In reverse order:
> > >
> > > > %languageometer.values ?+= rand;
> > >
> > > This is the same as
> > >
> > > all( %languageometer.values ) += rand;
> > >
> > > right?
> >
> > It's the same as
> >
> > $r = rand;
> > $_ += $r for %languageometer.values
> >
> > Your junction looks like it should work but I think you're really
> > adding the random number to the junction, not the elements that compose
> > the junction thus none of %languageometer.values are modified.
>
> It would be disappointing if junctions could not be lvalues.
Oh, I think that junctions can be lvalues but a junction is different
from the things that compose it. I.e.,
$a = 5; $b = 10;
$c = $a | $b;
$c += 5;
print "$a $b\n";
if $c > 10 { print "More than 10!\n"; }
would output
5 10
More than 10!
because the *junction* has the +5 attached to it rather than the
individual elements of the junction. Read the if statement as "if any
of (5 or 10) + 5 is greater than 10, ..." Which is the same as "if
any of 10 or 15 is greater than 10, ..."
I hope I'm making sense.
> > I don't think junctions apply at all in vectorization. They seem to
> > be completely orthogonal.
>
> I'm curious if that's true, of if they're two different ways of getting to
> the same data. (At least in the one-dimension case.)
I'm just waiting for Damian to speak up :-)
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
Re: Semantics of vector operations
On Thu, Jan 22, 2004 at 02:28:09PM -0700, Luke Palmer wrote:
: Well, for being called "vector operators", they're ending up pretty
: useless as far as working with mathematical vectors.
Which is why I suggested calling them distributors or some such.
: 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.
Yes, and I think we have to stick with the naive view of what Â*Â would
do, since there are times you simply want to do a bunch of multiplications
in parallel.
: 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.
I'd think it would make you even happier to just use the appropriate
Unicode operators directly (presuming there are such).
: 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([EMAIL PROTECTED], [EMAIL PROTECTED])
:
: (Hopefully when @A and @B are of equal length).
Yes, though in fact ÂÂ is supposed to do max() rather than min() here.
Which, in the case of arrays of equal length, comes out to the same
thing...
: 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.
Which says to me that outer product really wants to be something like
X or â or even â (shades of APL). In the for-what-it's-worth department,
it looks like Python might be using @ for that.
Larry
Re: Semantics of vector operations
On Thu, Jan 22, 2004 at 01:34:33PM -0600, Jonathan Scott Duff wrote: : On Thu, Jan 22, 2004 at 11:25:41AM -0800, Larry Wall wrote: : > Me? I handle it by making it an adverb on the base operator. :-) : : Does that mean it should get the colon? :) Only if all adverbs in English end in -ly. Of course, my name ends -ly in Japan--I had to learn to answer to "Rally" when I was there. So maybe I still get the colon... :-) : > I don't think that ?X? means "Do whatever the mathematicians want X : > to do." Unicode operators have to be good for something, after all. : > : > So perhaps its best to call ? and ? "distribution modifiers" or : > some such. : : Could someone put the non-unicode variants up there so those of us : with unicode-ignorant MUAs can know what exactly we're talking about? Those are just the German/French quotes that look like >> and <<. : Or alternatively (and certainly better), could someone clue me on how : to make mutt unicode-aware? Modern versions of mutt are already unicode aware--that's what I'm using. Make sure .muttrc has set charset="utf-8" set editor="vim"(or any editor that can handle utf-8) set send_charset="us-ascii:iso-8859-1:utf-8" The main thing is you have to make sure your xterm (or equivalent) unicode aware. This starts a (reversed video) unicode terminal on my machine: LANG=en_US.UTF-8 xterm \ -fg white -bg black \ -u8 \ -fn '-Misc-Fixed-Medium-R-Normal--18-120-100-100-C-90-ISO10646-1' I'm also using gnome-terminal 2.4.0.1, which knows how to do utf-8 if you tell it in the preferences. Of course, this is all from the latest Fedora Core, so your software might not be so up-to-date. And other folks might prefer something other than en_US. It's the .UTF-8 that's the important part though. I run some windows in ja_JP.UTF-8. And, actually, my send_charset is set send_charset="us-ascii:iso-8859-1:iso-2022-jp:utf-8" because I have Japanese friends who prefer iso-2022-jp because they don't know how to read utf-8 yet. Larry
Re: Semantics of vector operations
- Original Message - From: "Luke Palmer" <[EMAIL PROTECTED]> To: "Austin Hastings" <[EMAIL PROTECTED]> Cc: "Larry Wall" <[EMAIL PROTECTED]>; "Language List" <[EMAIL PROTECTED]> Sent: Thursday, January 22, 2004 4:28 PM Subject: [perl] Re: Semantics of vector operations > 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. I just realized a potential flaw here. Consider the code $a >>= 1; Will this right-shift the value of $a one bit and assign the result to $a (the current meaning)? Or will it assign the value 1 to each element in the array referenced by $a (as suggested by the new syntax). Both of these are perfectly valid operations, and I don't think its acceptable to have the same syntax mean both. I'm aware that using "Â=" instead of ">>=" will eliminate the inconsistency, but not everyone has easy access to Unicode keyboards. Joe Gottman
Re: Semantics of vector operations
On Thu, Jan 22, 2004 at 08:08:13PM -0500, Joe Gottman wrote: :I just realized a potential flaw here. Consider the code : $a >>= 1; : :Will this right-shift the value of $a one bit and assign the result to $a : (the current meaning)? Or will it assign the value 1 to each element in the : array referenced by $a (as suggested by the new syntax). Both of these are : perfectly valid operations, and I don't think its acceptable to have the : same syntax mean both. I'm aware that using "»=" instead of ">>=" will : eliminate the inconsistency, but not everyone has easy access to Unicode : keyboards. Well, $a >>=<< 1 would still presumably be unambiguous, and do the right thing, albeit with run-time dwimmery. On the other hand, we've renamed all the other bitwise operators, so maybe we should rename these too: +< bitwise left shift +> bitwise right shift which also gives us useful string bitshift ops: ~< stringwise left shift ~> stringwise right shift as well as the never-before-thought-of: ?< boolean left shift ?> boolean right shift Those last would be a great addition insofar as they could always participate in constant folding. Er, unless the right argument is 0, of course... :-) Ain't orthogonality wonderful... Larry
Re: Semantics of vector operations
Luke Palmer <[EMAIL PROTECTED]> writes: > @A »+« @B # One-at-a-time > @A «+» @B # Outer product > > Or something. Hmm, then both: > > @A »+ $b > @A «+ $b There is a page you may find inspiring: http://www.ritsumei.ac.jp/~akitaoka/index-e.html Sorry, I could not resist. :) The one-sided operators make sense to me but combining this with both « and » seems hard on the eyes. That being said I really like the general direction that Perl 6 is going and I'm looking forward to using it. You're all doing great work! back to lurking-mode -Edwin
Re: Semantics of vector operations
Larry Wall writes: > On Thu, Jan 22, 2004 at 08:08:13PM -0500, Joe Gottman wrote: > :I just realized a potential flaw here. Consider the code > : $a >>= 1; > : > :Will this right-shift the value of $a one bit and assign the result to $a > : (the current meaning)? Or will it assign the value 1 to each element in the > : array referenced by $a (as suggested by the new syntax). Both of these are > : perfectly valid operations, and I don't think its acceptable to have the > : same syntax mean both. I'm aware that using "Â=" instead of ">>=" will > : eliminate the inconsistency, but not everyone has easy access to Unicode > : keyboards. > > Well, > > $a >>=<< 1 > > would still presumably be unambiguous, and do the right thing, albeit > with run-time dwimmery. On the other hand, we've renamed all the > other bitwise operators, so maybe we should rename these too: > > ++>bitwise right shift I could have sworn we already did that. I thought they were: +<< +>> But I guess that's an extra unneeded character. Luke > which Ãlso gives us useful string bitshift ops: > > ~ ~>stringwise right shift > > as well as the never-before-thought-of: > > ? ?>boolean right shift > > Those last would be a great addition insofar as they could always > participate in constant folding. Er, unless the right argument is 0, > of course... :-) > > Ain't orthogonality wonderful... > > Larry
