
Boost : 
From: John Maddock (john_at_[hidden])
Date: 20051202 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/whyieee.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 littleendian. 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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk