----- Original Message ----- From: "John Peacock" <[EMAIL PROTECTED]> To: "Sisyphus" <[EMAIL PROTECTED]> Cc: "p5p" <perl5-porters@perl.org> Sent: Monday, July 25, 2005 8:42 PM Subject: Re: NaN on platforms that don't support it
> Sisyphus wrote: > > But on the 2 machines I ran that code on (linux and Win32), IEEE NaN is not > > supported - as evidenced by the fact that NaN + 1 == 1. > > NaN is supported on both of those platforms (AFAIK), Aaaah - I half expected it would be - but the perlop documentation implied that's not the case. > but the string "NaN" is not > a canonical way to generate the special IEEE NaN number. > I also tried using NaN as a bareword. It makes no difference to the behaviour - unless we 'use strict;' in which case the bareword is simply not allowed. > > I also checked by > > running (as suggested in perlop): > > > > perl -le '$a = NaN; print "No NaN support here" if $a == $a' > > I don't see support for that construct in the code at all (there is special INF > and NaN handling in numeric.c:Perl_grok_number but this only bypasses the > warning and doesn't affect the math), so I'm not sure that was ever anything > more than wishful thinking. I think the thought was that there would be special > handling so that this: > > $x = NaN; # note bareword not string > > would autogenerate an actual NaN number, but it doesn't exist (AFAICT) in toke.c > where it belongs. > Oh, I think I understand .... it's partly a case of inaccuracies in the perlop, perlfunc and perldata documentation of NaN and Infinity. (The documentation is a little ahead of itself :-) Until NaN and Infinity are properly implemented, I believe it would be best if perl reverted to treating these symbols simply as strings (as was the case with 5.6). It has been subsequently suggested on the c.l.p.misc thread that I should submit a 'perlbug' report about this. Should I do that ? Thanks John. Cheers, Rob
