Indeterminate forms for the Num type.

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Assuming "num" uses the underlying floating point semantic (which may turn 0/0 into NaN without raising exception), what should the default "Num" do on these forms? 0/0 0*Inf Inf/Inf Inf-Inf 0**0 Inf**0

Re: Indeterminate forms for the Num type.

Audrey Tang wrote: > Assuming "num" uses the underlying floating point semantic (which may > turn 0/0 into NaN without raising exception), what should the default > "Num" do on these forms? > > 0/0 > 0*Inf > Inf/Inf > Inf-Inf > 0**0 > Inf**0 >

Re: split on empty string

On 2006-01-17 12:24 PM, "Gaal Yahas" <[EMAIL PROTECTED]> wrote: > While cleaning up tests for release: > > "".split(':')=> > >()# Perl 5 >("",) # pugs > > Which is correct? It doesn's seem to be specced yet. I would prefer the current pugs behavior;

Re: Indeterminate forms for the Num type.

Physicist here. One who believes -2**2 is negative. At 23:26 +0800 1/17/06, Audrey Tang wrote: >Several options: >- - Use whatever the underlying "num" semantics available That's likely to be in hardware. It might even be hard to detect without looking at the NaN returned and that would be a was

split on empty string

While cleaning up tests for release: "".split(':')=> ()# Perl 5 ("",) # pugs Which is correct? It doesn's seem to be specced yet. -- Gaal Yahas <[EMAIL PROTECTED]> http://gaal.livejournal.com/

Re: Indeterminate forms for the Num type.

Doug McNutt wrote: >> - - Specify them to return some definite value. > Only on a machine that doesn't do it in hardware or in some special perl > function that's unlikely. This question arises as different platform answer things differently for the native calculation of eg. 1**Inf. > >> At this

Re: Indeterminate forms for the Num type.

On 1/17/06, Audrey Tang <[EMAIL PROTECTED]> wrote: > But putter on #perl6 reports "1" on his amd64. I'd be happy we spec it > has to have to return 1 always for boxed Num types, even though it means > additional cycles for boxed numeric types. Isn't the point of boxing to provide a hardware-indep

Re: Indeterminate forms for the Num type.

On 1/17/06, Audrey Tang <[EMAIL PROTECTED]> wrote: > I personally like having 0/0 be NaN and 1/0 be Inf (as in JavaScript), > but all of Python/Perl/Ruby/Scheme/OCaml throws exceptions for them... I believe we've been through this before. We go with a standard, probably IEEE, horridly mathematica

Re: Indeterminate forms for the Num type.

Luke Palmer wrote: > I believe we've been through this before. We go with a standard, > probably IEEE, horridly mathematically unappealing though it may be. > It will be easier to implement and it will be more predictable, both > because most other language follow standards, too. "The good thing

Re: Indeterminate forms for the Num type.

Audrey Tang wrote: > That seems to follow from the standard (ruby, ocaml, mzscheme currently > does that), but some may also argue for NaN bothways (ghc, js) or an > exception bothways (perl5, python). Er, wait, ghc also raises an exception for (div 0 0), because it distinguishes integer (div) wit

Re: Indeterminate forms for the Num type.

At 9:50 AM +0800 1/18/06, Audrey Tang wrote: However, I think one of P6's idea is that the user should not have to care between 0 and 0.0's behaviours, so maybe it makes sense to do the same thing (be it NaN or exception) both ways. I'm not sure that IEEE 754/854 still applies if we want to merg

Re: split on empty string

On Tue, Jan 17, 2006 at 12:35:57PM -0500, Mark Reed wrote: > On 2006-01-17 12:24 PM, "Gaal Yahas" <[EMAIL PROTECTED]> wrote: > > > While cleaning up tests for release: > > > > "".split(':')=> > > > >()# Perl 5 > >("",) # pugs > > > > Which is correct?