[several replies flattened into one] On Monday, July 15, 2002, at 01:45 PM, Sean O'Rourke wrote:
> On Mon, 15 Jul 2002, Luke Palmer wrote: > >> On Mon, 15 Jul 2002, Karl Glazebrook wrote: >> >>> @solution = (^-@b + sqrt(@b^**2 ^+ 4^*@a^*@c) ) ^/ (2^*@a); >> >> That would not be very pretty, indeed. It would also not be very >> efficient. (BTW, its b**2 - 4ac, not + :) A more efficient, pretty, yeah the minus sign got lost in all the clutter. My point I think :) >> and clear way would be like this: > > Not necessarily true! The compiler can figure out that a sequence of > operators is hyped and avoid the temporary arrays (like your for-loop). > It takes a little more work, but it's really not all that hairy when the > necessary information is right in the syntax. > > Furthermore, the beauty of the hyper-operators (or the implicitly-vector > normal operators below) is they don't give the programmer a loop body in > which to do wierd things to the arrays. Since > > @y = $a ^* @x ^+ @b > > is all a single operation from the user's perspective, the compiler can > make it faster than a loop written in pure Perl. This is exactly what happens in PDL currently, but instead you say $y = $a * $x + $b where everything is an object > I actually find myself using @a in numeric context quite a bit, but > would > have no objections to changing it to @a.length, since the former is > completely bizarre to someone not familiar with Perl. glad you agree. I want to hear what Larry says. > >> I wouldn't mind if this proposal was accepted, but I also think the >> hyper >> operator syntax is nice. At least for what I'm doing, in which it's >> usually Yet Another shorthand for a C<foreach> (or now just C<for>) >> loop. > > Maybe we could add a hyper-context to cut down on the line-noise without > startling Perl 5 programmers: > > @solution = ^( -@b + sqrt(@b**2 + 4*@a*@c) ) / (2*@a) ) Still looking ugly! > Or (this might break something): > > @solution ^= -@b + sqrt(@b**2 + 4*@a*@c) ) / (2*@a); > But would not work if there was no = sign - e.g. foo(@x * @b +1) > (then watch as people have all their inplace-array-bitwise-xors change > meaning;) > > I agree that the ^op syntax is painful if you have to type it a lot, but > for the majority of people not using Perl for numerical code, > hyper-operation is something out of the ordinary, and seems to deserve > syntactic markers. For example: > > my @things = @args || @defaults; # @args if it is true, else @defaults > # vs > my @things = @args ^|| @defaults; # $args[$_] || $defaults[$_] for 0..X > > If infix operators are implicitly vector, the first's becoming the > second > could be a bit surprising. Even more so since, if we're handling > infinite > lists, hyper-operators should iterate over the number of items in their > shorter argument. I say the latter is more useful and it is time to break with the past > > On Monday, July 15, 2002, at 01:03 PM, Erik Steven Harrison wrote: > > > Where I see a big win for hyper operators is in places where the > scafolding code ordinarly clutters the actual work. I like being able > to write > > @defaults ^//= 1; > > don't you? > > -Erik @defaults = 1 > On Monday, July 15, 2002, at 01:52 PM, Aaron Sherman wrote: > Sure, that's always an option. I think Perl has a lot going for it other > than the way vectorization happens, and with the ability to define your > own array behavior, you can pretty much do this however you want anyway. Yes but it would be nuts to have PDL arrays do things one way and inbuilt compact arrays do things another way. Karl
