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
>> 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
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).
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk