p5pRT
commented
22 years ago 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
Migrated from rt.perl.org#7501 (status was 'resolved')
Searchable as RT7501$