Re: [boost] Re: is_nan

From: Joel de Guzman (djowel_at_[hidden])
Date: 2003-07-13 05:39:56

Gabriel Dos Reis <gdr_at_[hidden]> wrote:
> "Joel de Guzman" <djowel_at_[hidden]> writes:
> 
>> Fernando Cacciola <fernando_cacciola_at_[hidden]> wrote:
>>> Gabriel Dos Reis <gdr_at_[hidden]> wrote in
>> 
>>>> Yes.  It is an incorrect (unfortunately popular)
>>>> implementation.
>>>> 
>>> Right. We should say that more often. It is incorrect
>>> however popular.
>>> 
>>> Most compilers provide a non standard extension for this
>>> purpose.
>>> For instance, Borland uses _isnan.
>>> In general, these extensions are found on <float>.
>>> The best approach, IMO, is to have a boost::is_nan() with
>>> compiler specific implementations.
>> 
>> Hi,
>> 
>> We have an is_nan(float) implementation (for quiet NaNs of course)
>> that does just that. Right now, it supports most compilers on Win32 but it
>> should be straight-forward to support others. Right now, it is tested on:
>> 
>>     g++2.95.3 (MinGW)
>>     g++3.1 (MinGW)
>>     Borland 5.5.1
>>     Comeau 4.24 (Win32)
>>     Microsoft Visual C++ 6
>>     Microsoft Visual C++ 7
>>     Microsoft Visual C++ 7.1
>>     Metrowerks CodeWarrior 7.2
>> 
>> The default implementation assumes IEEE754 floating point. It takes advantage
>> of the fact that IEEE754 has a well defined binary layout for quiet NaNs.
> 
> I'm not sure what you mean by that.  IEEE-754 defines an *abstract*
> binary model, not a concrete one.  And the exact mapping to concrete
> implementation is NOT defined.  That is not what I call a well defined
> binary layout.

Yes of course. What's important is that it defines the bits of what constitutes a 
NaN, b[0] .. b[N] and we can create a mapping from bits 0..N of the abstract
binary model to the actual (concrete) binary layout of a platform/processor.

> For example on HP boxes, the concrete binary layout of qNaNs and sNaNs
> is flipped (in the leading bits) from those of SPARCs.  Yes, both have
> IEEE-754 conforming  representations.  There are many other variants.
> (I learnt those when I tried to get compiler support for
> numeric_limits<> in GCC).  Those who are interested might want to have
> a look at gcc/real.[hc].

Nice. Thanks for the tip.

-- 
Joel de Guzman
joel at boost-consulting.com
http://www.boost-consulting.com
http://spirit.sf.net