Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c++ > #14680 > unrolled thread

NaN values in c++

Back to article view | Back to comp.lang.c++

Contents

  NaN values in c++ Luca Cerone <luca.cerone@gmail.com> - 2012-03-02 01:24 -0800
    Re: NaN values in c++ "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> - 2012-03-02 11:43 +0100
      Re: NaN values in c++ Marc <marc.glisse@gmail.com> - 2012-03-02 11:33 +0000
        Re: NaN values in c++ Luca Cerone <luca.cerone@gmail.com> - 2012-03-02 08:01 -0800
          Re: NaN values in c++ Paavo Helde <myfirstname@osa.pri.ee> - 2012-03-02 11:14 -0600
        Re: NaN values in c++ Miles Bader <miles@gnu.org> - 2012-03-03 07:35 +0900

#14680 — NaN values in c++

Dear all,
is there in c++ an analogous of Matlab NaN values?
In Matlab NaN is a special value that you can assign
to double variables and use it for example to mark special position
in vectors (for example imagine a polygon made of two disjoint regions,
you can separate the two regions using NaN),
it is the value returned when making a 0/0 division and so on

Is there any such special value in c++? Googling I think there is
and that I have to use a <limit> library, but I couldn't really
find more information, especially concerning the efficiency of such a library.

Thanks a lot in advance for your help in advance,
Luca

[toc] | [next] | [standalone]

#14683

On 02.03.2012 10:24, Luca Cerone wrote:
> Dear all,
> is there in c++ an analogous of Matlab NaN values?
> In Matlab NaN is a special value that you can assign
> to double variables and use it for example to mark special position
> in vectors (for example imagine a polygon made of two disjoint regions,
> you can separate the two regions using NaN),
> it is the value returned when making a 0/0 division and so on
>
> Is there any such special value in c++? Googling I think there is
> and that I have to use a<limit>  library, but I couldn't really
> find more information, especially concerning the efficiency of such a library.

The C++ standard does not require a floating point representation that 
does have NaN, but usually it will be by default be IEEE 754, which does 
support NaN and Infinity values.

Even the C++03 standard let you test for the presence of NaN support, like

    typedef std::numeric_limits<double> Fp;
    std::cout << std::boolalpha;
    std::cout << "Has quiet Nan: " << Fp::has_quiet_NaN << "\n";
    std::cout << "Has signaling NaN: " << Fp::has_signaling_NaN << "\n";

And it let you test for IEEE 754 conformance:

    std::cout << "Is IEEE 754: " << Fp::is_iec559 << "\n";

The main problem with that was and is that implementations such as 
Visual C++ and the GNU toolchain let the user choose optimizations where 
the floating point behavior is decidedly not IEEE 754 conforming.

So you can't even reliably test for IEEE 754.

You just have to document requirements very cleary, e.g. "this library 
requires IEEE 754 conformance, don't use e.g. -fastmath option".

And in particular that the unreliability applies to testing for NaN, 
which with a conforming implementation would be easy, like

    x != x   // If so, then with conforming impl. we have a NaN.

With C++03 you could test for NaN in platform-specific ways, like using 
Posix isnan macro or Visual C++ _isnan runtime library function. But it 
was difficult to write portable code that way. The platform checking was 
akin to browser-detection on the web: an ungood way to do things.

Happily the C++11 standard, by incorporating most of the C99 standard 
library, requires a common isnan() function:

<code>
#include <iostream>
#include <math.h>           // is_nan
#include <limits>           // std::numeric_limits

#ifdef  _MSC_VER
     inline int isnan( double x ) { return _isnan( x ); }
#endif

int main()
{
     using namespace std;
     typedef numeric_limits<double>  Fp;
     cout << boolalpha;

     cout << "Example NaN output: " << Fp::quiet_NaN() << endl;
     cout << "3.15 is NaN? " << !!isnan( 3.14 ) << endl;
     cout << "NaN is NaN? " << !!isnan( Fp::quiet_NaN() ) << endl;
}
</code>

The above code reflects that std::isnan() is not yet implemented in 
Visual C++ 10.0, which is the current version of Visual C++.


Cheers & hth.,

- Alf

[toc] | [prev] | [next] | [standalone]

#14686

"Alf P. Steinbach"  wrote:

> The main problem with that was and is that implementations such as 
> Visual C++ and the GNU toolchain let the user choose optimizations where 
> the floating point behavior is decidedly not IEEE 754 conforming.
> 
> So you can't even reliably test for IEEE 754.
> 
> You just have to document requirements very cleary, e.g. "this library 
> requires IEEE 754 conformance, don't use e.g. -fastmath option".
> 
> And in particular that the unreliability applies to testing for NaN, 
> which with a conforming implementation would be easy, like
> 
>     x != x   // If so, then with conforming impl. we have a NaN.
> 
> With C++03 you could test for NaN in platform-specific ways, like using 
> Posix isnan macro or Visual C++ _isnan runtime library function. But it 
> was difficult to write portable code that way. The platform checking was 
> akin to browser-detection on the web: an ungood way to do things.
> 
> Happily the C++11 standard, by incorporating most of the C99 standard 
> library, requires a common isnan() function:

I don't see how that changes anything. -ffinite-math-only (implied by
-ffast-math) is a way for the user to say that there won't be a NaN
(or an infinity) anywhere. That flag is then likely to replace isnan
with a function that always returns false.

Documenting that your program requires a standard-conforming compiler
does look like the only option.

[toc] | [prev] | [next] | [standalone]

#14693

> > The main problem with that was and is that implementations such as 
> > Visual C++ and the GNU toolchain let the user choose optimizations where 
> > the floating point behavior is decidedly not IEEE 754 conforming.
> > 

I'm sorry guys but I don't follow very well what you're saying.
I need a special value to mark positions in my vectors of double.
Being an experienced Matlab user, using a NaN seemed the option that made
more sense.

Why in C++ NaN cause issues? And if NaN is not a feasible solution,
how would you recommend to implement a special double value to mark
special positions in your vectors?
Thanks a lot, and sorry if I couldn't understand at all your arguments.

Cheers, Luca

[toc] | [prev] | [next] | [standalone]

#14695

Luca Cerone <luca.cerone@gmail.com> wrote in
news:10810867.7.1330704117801.JavaMail.geo-discussion-forums@vbbdh9: 

>> > The main problem with that was and is that implementations such as 
>> > Visual C++ and the GNU toolchain let the user choose optimizations
>> > where the floating point behavior is decidedly not IEEE 754
>> > conforming. 
>> > 
> 
> I'm sorry guys but I don't follow very well what you're saying.
> I need a special value to mark positions in my vectors of double.
> Being an experienced Matlab user, using a NaN seemed the option that
> made more sense.

Just use std::numeric_limits<double>::quiet_NaN() as that value and do 
not worry too much. You probably want to give it a shorter name, e.g.

#include <limits>
const double kNaN = std::numeric_limits<double>::quiet_NaN();

> 
> Why in C++ NaN cause issues? 

Because C++ is meant to be implemented on by far more platforms than 
MatLab, and not all those platforms might support NaN. Probably you will 
never encounter such platforms though.

> And if NaN is not a feasible solution,
> how would you recommend to implement a special double value to mark
> special positions in your vectors?

One could define a custom C++ class emulating IEEE floating-point 
behavior. However, this would be an overkill if you have no intentions to 
target those exotic platforms.

Cheers
Paavo

[toc] | [prev] | [next] | [standalone]

#14698

Marc <marc.glisse@gmail.com> writes:
>> You just have to document requirements very cleary, e.g. "this library 
>> requires IEEE 754 conformance, don't use e.g. -fastmath option".
...
>> Happily the C++11 standard, by incorporating most of the C99 standard 
>> library, requires a common isnan() function:
>
> I don't see how that changes anything. -ffinite-math-only (implied by
> -ffast-math) is a way for the user to say that there won't be a NaN
> (or an infinity) anywhere. That flag is then likely to replace isnan
> with a function that always returns false.

... and indeed that does happen in gcc.

One could probably get around this in practice by using one's own
external "really_is_nan" function, making sure that it's compiled
without -ffast-math or whatever...

-Miles

-- 
Quidquid latine dictum sit, altum viditur.

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.c++

csiph-web