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 :-(