-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Matthew Markland Sent: Tuesday, July 17, 2012 7:49 PM To: boost@lists.boost.org Subject: Re: [boost] Boost.config limits_test testcase and qnan checks

MARKLAND> My question is whether it is valid to test the qnan behavior MARKLAND> when a platform MARKLAND> > does not claim compliance?

...

I wonder how you measure "claim compliance"? I once had a long debug session with gcc-4.5.2 before I found out that the builtin "is_nan" was returning wrong results. Isn't compiling the code that uses "is_nan" without warning also some sort of "compliance claim"? I know you are probably referring to "numeric_limits<double>::is_iec559", but on which floating point functionality can I still rely as a programmer if (is_iec559 == false)?

...

Thomas

I've now been trying to come up with a good answer to this for days and have yet to get there. So I'm going to just comment and see if the discussion continues. These are my interpretations and should not be construed as the opinion of my employer.

In the case of this particular test, from a language perspective, I think the check for is_iec559 makes sense. The part of the test in question is testing a behavior that is only defined for certain if the platform is using an IEEE compliant implementation. Now this doesn't mean that it won't work for a platform that sets is_iec559() to false, but to me it is only guaranteed if is_iec559() is true.

As for what you can rely on if is_iec559() is false, that is a good question. Most of the items in numeric_limits<> appear to require explicit checks for availability if is_iec559() is false. My readings of the Standards (C/C++) seem to show them to be silent on what happens with a function like isnan() if is_iec559() is false. Most of what I've seen on the web is that these functions are of dubious usefulness due to optimizations performed. Clearly one would like to expect that if the compiler is being used at an optimization level that breaks floating-point compliance then is_iec559() would be set to false, but from what I've read that isn't a safe expectation. I guess you're at the mercy of your compiler vendor to describe their levels of support and what these functions may mean.

"Now this doesn't mean that it won't work for a platform that sets is_iec559() to false, but to me it is only guaranteed if is_iec559() is true."

Yes - I fear you are right that we are implementation-dependent. But I can't see why a non-IEC559 platform, it is not possible for it to provide NaN support, even if it was different in detail of what was the representation of a NaN. But to be useful would also require that isnan() knew about that platform, its peculiar implementation, and the effect of any compiler optimisations, and that the values like is_qnan etc are truthful. (I fear that compiler providers have yet to focus on the subtle side-effects of speedups - as Thomas reports - and debugging will prove a nightmare because you find yourself in a morass of macros). So lots more niggly work - (that I'd prefer to avoid! ;-) But the concept is NaN remains very useful to me and I use it freely, perhaps unwisely;-) It certainly beats some other arbitrary 'magic' value to represent NotANumber. Paul