Karl Glazebrook:
# 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!

That statement looks ugly anyways.

        $solution = -$b + sqrt($b**2 + 4*$a*$c) / (2*$a);

Ugly, ugly, ugly.  It needs more spacing to make it pretty, not fewer
carrots.

Besides, mistakes like this are the alternative:

        #This should be $baz, not $foo...
        $foo=something_that_returns_an_infinite_array_ref();
        ...
        #1654 lines later...
        $bar=$foo ** 2; #Anyone have a date for the heat death of the
Universe?

If the hyperoperization was implicit, the guy who wrote this would be
sitting there twiddling his thumbs till he died.

Now imagine that that error was in a CGI script running on Apache/NT.
He *can't* kill the Perl process and make life better--he doesn't have
the access.  (I've learned this point the hard way.  :^) )

With explicit, you just get the result of Inf ** 2 (which presumably is
still Inf) in $bar.  Perhaps neither is what you want, but at least it
doesn't take forever to run.

# > 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

I say we shouldn't decide for the user what's more useful.  Personally,
I think the first is more useful, but that's irrelevant.  With implicit
vectorization, they have to jump through hoops to get the first one.  So
many hoops, in fact, that I can't even think of a decent way to do it.
(@args.length ?? @args :: @defaults would work, but that's horrible.)
With explicit, one of the ways of doing it is one character longer, but
at least the other one is *possible to do*.

# > 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

Somehow, that seems wrong to me...

# > 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.

No, it wouldn't.  PDL is supposed to be like the venerable language
Math.  Math treats numbers and more complex objects (like matrices)
exactly the same (operator-wise).  Therefore, PDL should treat numbers
and more complex objects exactly the same (operator-wise).

--Brent Dax <[EMAIL PROTECTED]>
@roles=map {"Parrot $_"} qw(embedding regexen Configure)

He who fights and runs away wasted valuable running time with the
fighting.

Reply via email to