Re: inf handling in Perl incomplete

[p5pRT]

Migrated from rt.perl.org#7500 (status was 'resolved')

Searchable as RT7500$

[p5pRT]

From kstar@wolfetech.com

  My reading of IEEE is that 0/0 is NaN\, and semantically\, NaN != NaN\, so the above should never print.

print "spooky\n" if NaN == NaN; # should never print print "ooky\n" if NaN == 1; # should never print. But does.

I don't believe that the Perl documentation claims that the bareword

`NaN' becomes an IEEE NaN in numeric context. It just suggests that an IEEE NaN is `NaN' in string context. Do you believe otherwise\, or are you proposing a change?

Incidentily\, up until today (well\, 2 hours ago)\, I believed and would have swonr that 'NaN' becomes an IEEE NaN. Oups. Can (read​: is it possible) to change that?

  Anything's possible. I'm not in favor of it\, because it will surprise too many numerically-casual people who expect any string that doesn't look like an everyday number to be numerically zero.

Problem arise also with use Math​::BigInt :constant; It won't touch NaN\, nor inf because these are strings (barewords)\, and are thus not integer constants. But Math​::BigInt->new('inf') works fine\, so :constant could (should) cover them. Or so I think.

  Correct on both counts\, but I wouldn't characterize the first as a problem. The overloading mode of Math​::BigInt is designed to be an easy upgrade to an already-working script. If you have a script that has bareword Nan and inf in it\, it's already broken.

  I don't want to see bareword NaN and Inf upgrade automagically. I think it's more cruft\, and there isn't just one NaN anyway. I wouldn't mind a pragma that made\, e.g.\, 0/0 or sqrt(-1) return the appropriate NaN instead of throwing an exception\, though.

  - Kurt

[p5pRT]

From @jhi

Ahhh\, true. Don't know what I was thinking.

I don't want to see bareword NaN and Inf upgrade automagically\.  I think

it's more cruft\, and there isn't just one NaN anyway. I wouldn't mind a pragma that made\, e.g.\, 0/0 or sqrt(-1) return the appropriate NaN instead of throwing an exception\, though.

I am in the process of adding some more guts support for infinities and nans. Well\, I *was* in the process of doing that but then the fileserver where my working directory is\, gave up the delivering-the-bits-business.

P.S. Pssst\, you certain you don't want sqrt(-1) returning 'i'? :-)

[p5pRT]

From @jhi

Ahhh\, true. Don't know what I was thinking.

I don't want to see bareword NaN and Inf upgrade automagically\.  I think

it's more cruft\, and there isn't just one NaN anyway. I wouldn't mind a pragma that made\, e.g.\, 0/0 or sqrt(-1) return the appropriate NaN instead of throwing an exception\, though.

I am in the process of adding some more guts support for infinities and nans. Well\, I *was* in the process of doing that but then the fileserver where my working directory is\, gave up the delivering-the-bits-business.

P.S. Pssst\, you certain you don't want sqrt(-1) returning 'i'? :-)

[p5pRT]

From [Unknown Contact. See original ticket]

  You joke\, but this is the logical extreme of the Magical Bearword Numerics path​:

  $x = i; # sqrt(-1)   $x = UNICODE_FOR_ALEPH_NULL; # Inf   $x = UNICODE_FOR_EPSILON; # DBL_MIN

  Before you know it\, we have native support for Conway numbers\, then we're APL.

  Bareword NaN should not become IEEE NaN. QED.

  - Kurt

[p5pRT]

From [Unknown Contact. See original ticket]

Sure; I want to see what you make sqrt(sqrt(-1)) return -- in scalar context. :-)

[p5pRT]

From [Unknown Contact. See original ticket]

Sure; I want to see what you make sqrt(sqrt(-1)) return -- in scalar context. :-)

[p5pRT]

From @abigail

  Math​::Complex -> emake (1\, pi/8)

Abigail

[p5pRT]

From @abigail

  Math​::Complex -> emake (1\, pi/8)

Abigail

[p5pRT]

From [Unknown Contact. See original ticket]

On Fri\, Aug 10\, 2001 at 10​:46​:38AM -0700\, Steve Fink wrote​:

P.S. Pssst\, you certain you don't want sqrt(-1) returning 'i'? :-)

Sure; I want to see what you make sqrt(sqrt(-1)) return -- in scalar context. :-)

Math​::Complex \-> emake \(1\, pi/8\)

You mean pi/4\, but I get the point. And reading the Math​::Complex documentation\, I get my answer -- it just picks one; if you want both\, you use root(). Hmf. Seems like a cop-out.

Perhaps the real answer is use Quantum​::Superpositions; any(root(i))?

[p5pRT]

From [Unknown Contact. See original ticket]

On Fri\, Aug 10\, 2001 at 10​:46​:38AM -0700\, Steve Fink wrote​:

P.S. Pssst\, you certain you don't want sqrt(-1) returning 'i'? :-)

Sure; I want to see what you make sqrt(sqrt(-1)) return -- in scalar context. :-)

Math​::Complex \-> emake \(1\, pi/8\)

You mean pi/4\, but I get the point. And reading the Math​::Complex documentation\, I get my answer -- it just picks one; if you want both\, you use root(). Hmf. Seems like a cop-out.

Perhaps the real answer is use Quantum​::Superpositions; any(root(i))?

[p5pRT]

From @jhi

Wrong. A conscious design decision. You don't want

  print "foo = "\, sqrt($a)\, "\n";

printing e.g.

  foo = i-i

Perhaps the real answer is use Quantum​::Superpositions; any(root(i))?

[p5pRT]

From @jhi

Wrong. A conscious design decision. You don't want

  print "foo = "\, sqrt($a)\, "\n";

printing e.g.

  foo = i-i

Perhaps the real answer is use Quantum​::Superpositions; any(root(i))?

[p5pRT]

From [Unknown Contact. See original ticket]

On Wed\, Aug 08\, 2001 at 11​:26​:42PM +0200\, Tels wrote​:

On 08-Aug-01 Kurt D. Starsinic tried to scribble about​:

On Wed\, Aug 08\, 2001 at 09​:11​:56AM +0100\, Piers Cawley wrote​:

Jarkko Hietaniemi \jhi@​iki\.fi writes​:

While that someone is at it\, "NaN" also needs fixing. In there one needs to move more carefully\, since there usually are two kinds​: "signaling" and "quiet" NaNs. The first kind gives SIGFPEs\, the second doesn't.

$x = NaN; print "goofy\n" if 0/0 == NaN; # should always print

My reading of IEEE is that 0/0 is NaN\, and semantically\, NaN \!= NaN\, so

the above should never print.

print "spooky\n" if NaN == NaN; # should never print print "ooky\n" if NaN == 1; # should never print. But does.

I don't believe that the Perl documentation claims that the bareword

`NaN' becomes an IEEE NaN in numeric context. It just suggests that an IEEE NaN is `NaN' in string context. Do you believe otherwise\, or are you proposing a change?

Incidentily\, up until today (well\, 2 hours ago)\, I believed and would have swonr that 'NaN' becomes an IEEE NaN. Oups. Can (read​: is it possible) to change that?

Anything's possible\.  I'm not in favor of it\, because it will surprise

too many numerically-casual people who expect any string that doesn't look like an everyday number to be numerically zero.

Well\, something *is* happening because C\<'NaN' == 1> is returning true\, whereas \<'foo' == 1> returns false (under Mandrake linux\, glib-2.2). I'd suggest that either NaN get fixed to work properly or that this special casing get removed entirely.

[...]

I don't want to see bareword NaN and Inf upgrade automagically\.  I think

it's more cruft\, and there isn't just one NaN anyway. I wouldn't mind a pragma that made\, e.g.\, 0/0 or sqrt(-1) return the appropriate NaN instead of throwing an exception\, though.

sqrt(-1) is a number\, but it's a complex one. 0/0 emphatically isn't a number.