Subject: Re: [boost] Boost.config limits_test testcase and qnan checks
From: Paul A. Bristow (pbristow_at_[hidden])
Date: 2012-07-18 10:24:14
> -----Original Message-----
> From: boost-bounces_at_[hidden] [mailto:boost-bounces_at_[hidden]] On Behalf Of Matthew
> Sent: Tuesday, July 17, 2012 7:49 PM
> To: boost_at_[hidden]
> 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
> 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
> 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
> 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
> 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
> 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,
> what I've read that isn't a safe expectation. I guess you're at the mercy of your compiler vendor
> 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
(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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk