Re: [boost] Boost.config limits_test testcase and qnan checks

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
> Markland
> 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
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