Austin Hastings:
# --- Dan Sugalski <[EMAIL PROTECTED]> wrote:
# > At 8:30 AM -0400 7/16/02, Karl Glazebrook wrote:
# > >I still feel this adds yet another layer of inconsistency and
# > >confusion. I can't look at a piece of code and know what it does,
# > >without referring up N lines to the to
--- Dan Sugalski <[EMAIL PROTECTED]> wrote:
> At 8:30 AM -0400 7/16/02, Karl Glazebrook wrote:
> >I still feel this adds yet another layer of inconsistency and
> >confusion. I can't look at a piece of code and know what it does,
> >without referring up N lines to the top of the scripts.
> >
> >
At 8:30 AM -0400 7/16/02, Karl Glazebrook wrote:
>I still feel this adds yet another layer of inconsistency and
>confusion. I can't look at a piece of code and know what it does,
>without referring up N lines to the top of the scripts.
>
>How is the infinite loop problem any different from other
I still feel this adds yet another layer of inconsistency and confusion.
I can't look at a piece of code and know what it does, without referring
up N lines to the top of the scripts.
How is the infinite loop problem any different from other Halting problems?
Karl
Christian Soeller wrote:
>
Trey Harris wrote:
> Yes. This is my fear of hyperoperation being the default for normal
> aggregates. Loops--and large, multiply-nested, potentially-infinite
> ones--can spring out of code that doesn't look loopy at all. Erm... you
> know what I mean. :-)
>
> Karl, do you have any objection
In a message dated Mon, 15 Jul 2002, Brent Dax writes:
> 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.
Yes. This is my fear of hyperoperation being the default for no
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
At 2:09 PM -0400 7/15/02, Karl Glazebrook wrote:
>
>>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 prett
[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, ind
On Mon, 2002-07-15 at 11:29, Karl Glazebrook wrote:
> complex formulae. Imagine:
>
> @solution = (^-@b + sqrt(@b^**2 ^+ 4^*@a^*@c) ) ^/ (2^*@a);
>
> (or would it be ^sqrt() ?) - This looks like sendmail :-)
I would imagine that non-binary operators would simply have a hyper-form
(which could
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,
>Karl Glazebrook <[EMAIL PROTECTED]> disgusted:
>
> @solution = (^-@b + sqrt(@b^**2 ^+ 4^*@a^*@c) ) ^/ (2^*@a);
>[Stuff]
>If I was forced to write vector code like this I *WILL* give up on perl,
>and resort to Numerical
>Python or IDL instead.
>
You can always use the map and foreach lik
On Mon, 15 Jul 2002, Karl Glazebrook wrote:
> In Apocalypse 2 Larry Wall wrote:
>
> > RFC 082: Arrays: Apply operators element-wise in a list context
> >
> > APL, here we come... :-)
> >
> > This is by far the most difficult of these RFCs to decide, so I'm going
> > to be doing a lot of thinkin
13 matches
Mail list logo
