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

Subject: Re: [boost] Boost.config limits_test testcase and qnan checks
From: John Maddock (boost.regex_at_[hidden])
Date: 2012-07-18 10:37:17

>> "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.

Definitely niggley - I'm currently trying to solve a bug report relating to 
floating point on SSE2 registers with the DAG or FTZ flags set - in these 
cases denorms are either not present (even though numeric_limits claims they 
are), or are present but get "randomly" set to zero depending upon whether 
we're dealing with the 32 or 64 bit architecture, and/or what instructions 
the compiler happens to emit where :-(

Not fun!

John.