Re: [boost] Re: is_nan

From: Gabriel Dos Reis (gdr_at_[hidden])
Date: 2003-07-13 03:27:38

"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.

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].

-- Gaby