Re: [boost] [math] floating point classification -testing helpwanted

From: Ian McCulloch (ianmcc_at_[hidden])
Date: 2005-12-01 15:09:27

John Maddock wrote:

>> The sign is actually the one information of a NaN you don't want to
>> get
>> back. The IEEE-754 standard explicitly mandates that NaN do not have a
>> sign (or more precisely, the sign of a NaN is not part of its
>> payload).
>>
>> All the other bits of a NaN value are important however. They are its
>> payload and are supposed to be stable through arithmetic operations
>> (except when an operation involves two NaNs). As a matter of fact,
>> NaNs
>> were conceived to carry information (debug information mainly).
>>
>> At a time, there even were discussions on revising the IEEE-754
>> standard
>> to describe a syntax like NaN0x3ff800. This proposal was withdrawn
>> because it was so high-level, but it should give an idea on what NaNs
>> were about.
> 
> Understood. Thanks for the information.  The basic problem here is that
> there is no portably way to get at that information, frexp yields
> undefined behaviour if pass it a NaN for example :-(
> 
> Likewise there is no portable way to create a NaN with a specific payload
> (that I'm aware of), not even in C99.

I guess you are referring to the C99 function double nan(const char *tagp)
here.  C99 doesn't specify any particular semantics for tagp however, but
at least among IEEE-754 platforms, is there much variation?  I just tried
playing around with this on g++ 3.4, and nan("str") appears to return
0x7FF8000000000000 + strtol("str") (as long as it is in range).

But I can't seem to find any sensible way of reading off what the nan
payload actually is.  Printf() with %f or %F appears to allow an output of
"NAN*" where the "*" is unspecified.  But g++ doesn't actually do it, it
just prints "nan" or "NAN", irrespective of the payload.  I would have
expected it would be symmetric with strtod, which allows notation
strtod("NAN(str)") and is equivalent to nan("str") (that, at least, is
C99).  Ugh!

Are there any floating point formats in use that allow NaN's, other than
IEEE-754?  It might be easier to just ignore the existing functions that
have inconsistent behaviour and write our own.

Cheers,
Ian