Re: NaNs
On 2008-07-27 17:47:51 -0400, Tom <spamfood@nothing.com> said:
I have some questions regarding NaNs for floating-point types:
First, am I correct that NaNs are NOT trap values, that is reading a NaN
itself (but not using it in an arithmetic expression) does not
automatically yield UB?
I guess the following snippet below is OK, correct?:
double X = std::numeric_limits<double>::quiet_NaN();
// some code
if (X == std::numeric_limits<double>::quiet_NaN())
...
else
...
As Thomas Richter pointed out, different hardware uses different
varieties of floating-point, so there is no absolute rule. On the other
hand, both C and C++ give favored status to IEEE-754 floating-point,
and many hardware systems implement it, so it's a good base for
understanding.
Yes, by default, NaN values are not trap values, properly understood.
But various operations on floating-point values do cause a trap. There
is a great deal of confusion here because the first "trap" is not the
same word as the second "trap". Similarly, some floating-point
operations cause exceptions, but those are not C++ exceptions.
Floating-point operations have their own terminology, and you have to
interpret statements about them from that perspective.
You get a floating-point exception when something out of the ordinary
occurs: dividing 0.0 by 0.0, dividing 1.0 by 0.0, etc. By default,
those exceptions simply set a bit in the floating-point flags which you
can test later, and return a special value: NaN for the first one,
infinity for the second. There are functions in C99 and in the upcoming
C++0x standard to check and to clear those flags.
Under IEEE-754 you can install a function as a "trap handler"; it will
be called whenever the floating-point exception you've attached it to
occurs. There's no support for trap handlers in C99 nor in C++0x.
This kind of a "trap" is not the same as the C99 term "trap
representation", which refers to a value that produces undefined
behavior when you access it. In the absence of a trap handler, IEEE-754
floating-point operations have well-defined behavior.
One of the quirks of NaN values is that they compare unequal to all
other values, including NaNs. So the test in the code snippet above
will always fail. Similarly, X == X will be false when X is a NaN.
Second, 18.2.1.2 of the C++-Standard describes some utility-functions of
numeric_limits, including NaN related. The (non-normative) note to these
functions says "required by LIA-1". Please, what is LIA-1. And moreover,
how shall I read that note practically speaking? Although the note is of
course non-normative, can I interpret it in a way that practically every
realized platform will offer me NaNs for float, double and long double ?
LIA-1 refers to ISO/IEC 10967-1, "Language independent arithmetic -
Part 1". As you say, those are footnotes, and LIA-1 is not one of the
normative references listed in the front of the standard. So you can't
assume that LIA-1 applies, nor can you assume that IEEE-754 applies.
Floating-point is still highly implentation dependent.
Third, are there any intended changes to NaNs in the upcoming version of
the Standard?
No, other than adding some C99 stuff like isnan() for detecting them.
--
Pete
Roundhouse Consulting, Ltd. (www.versatilecoding.com) Author of "The
Standard C++ Library Extensions: a Tutorial and Reference
(www.petebecker.com/tr1book)
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]