in reply to nans, infs, and vomit

No IEEE rationale, the standard dealing with this stuff is IEEE 754 (and its revision IEEE 754r) but it only discusses things like the bit patterns for representing those values.

I recently followed the discussion on your post How to create nan/inf with interest. In Perl 6 everything will be better, but when I read A Romp Through Infinity I was a bit puzzled/confused.

In mathematics it is well defined but outside of math it seems to depend on the specific domain, i.e. you can find thousands of papers discussing infinity/NaN on IEEE. Enjoy:-)

Cheers,
dHarry

Update:
IEEE-754 References for the NaN/Inf inclined monk.

Replies are listed 'Best First'.
Re^2: nans, infs, and vomit
by syphilis (Archbishop) on Sep 01, 2008 at 14:17 UTC
    No IEEE rationale

    In a nutshell then ... what is it that inspired this notion that the strings "nan"/"inf" should actually become nans/infs when used numerically ? Was it something that the perl porters dreamed up all by themselves ?

    It sure has been giving me some headaches lately. (Actually, it's the lack of uniformity across different operating systems that's the problem. If they all did the same thing, no matter how distasteful that "same thing" was, life would be much simpler :-)

    Cheers,
    Rob
        http://www.perl.com/doc/FMTEYEWTK/is_numeric.html

        Yes - that puts this behaviour into context. When any string is put into numeric context, perl just hands that string over to the underlying C implementation of atof(), and we're then at the mercy of what that function does with the string it has been passed.

        On some systems, atof turns the strings 'nan' and 'inf' into actual nans and infinities. On other implementations of atof,a nan/inf will never result from a call to atof - irrespective of what string it receives. This is not a very convenient situation ... but we can't blame perl for differences in the underlying C libraries.

        Thanks for the link Anonymous Monk.

        Cheers,
        Rob