Re: [boost] [math] floating point classification - testinghelpwanted

From: John Maddock (john_at_[hidden])
Date: 2005-12-02 07:22:22

> but otherwise once a NaN always a NaN :-) Agreed - but worth a
> comment?

Agreed.

>> That's the problem: there is no portably way to create NaN's
>> with other payloads, not even with ldexp.
>
> That is true.
>
> And it leaves me most unsatisfied, feeling frustrated that we are not
> getting what the IEEE754 designers intended.
>
> We don't seem to have made ANY progress since Kahan's note in 1997
>
> http://www.cs.berkeley.edu/~wkahan/ieee754status/IEEE754.PDF
>
> http://www.cs.berkeley.edu/~wkahan/ieee754status/why-ieee.pdf

Very depressing reading.

> I feel that there __ought__ to be some debug use in getting the NaN
> values, as Guillaume Melquiond noted, but do need to be able to
> get/put the bits.
>
> Considering the amount of MACRO bodging that Boost is doing to create
> portability, I wonder if we should not try to produce some way of
> getting/putting at the 'internal' IEEE representation at least.
> There are surely not THAT many combinations?  We should know how many
> exponet and significand bits from numeric_limits (so also know if
> VAX/Alpha without denorm), and if big or little-endian. What others
> (apart from decimal, a different ball game).
>
> Stephen Moshier has already done a LOT of this bit twiddling for
> Cephes for IBMPC (X86), DEC (VAX) and M68000 for 32, 64, 80 and 128
> bit sizes.

Yep: the formats are mostly well known and the bit twiddling isn't that hard 
once you know what the format is, but there's at least one problem case: 
long double's on Darwin.  I can't find any information on these after a 
quick google search, but I believe they're effectively a sum of two doubles. 
If so this is exceptionally bad form because it violates the most 
fundamental principal of IEEE arithmatic that a number is n*2^k. 
(Background: epsilon is very small for this type, it's possible to add a 
number "delta" to 1.0L and still get a distict value when "delta" is much 
smaller than the number of bit's in a long double would otherwise indicate. 
This makes a *lot* of IEEE based reasoning invalid.  If anyone has more 
information on this type I'd appreciate a reference).

John.