From: Paul A Bristow (pbristow_at_[hidden])
Date: 2005-12-02 06:24:25
| -----Original Message-----
| From: boost-bounces_at_[hidden]
| [mailto:boost-bounces_at_[hidden]] On Behalf Of John Maddock
| Sent: 01 December 2005 19:18
| To: boost_at_[hidden]
| Subject: Re: [boost] [math] floating point classification
| That's a Boost.Test issue.
Already reported to Gennadiy.
| I'm relying on the fact that a cast to a narrower or wider
| type will never
| create or destroy a NaN: we may get underflow to zero, or overflow to
but otherwise once a NaN always a NaN :-) Agreed - but worth a comment?
| > But I note that you have only tested with two of the considerable
| > range of possible NaN.
| > FFFFFFFF to FF800001 and 7F800001 to 7FFFFFFF for 32 bit.
| > FFFFFFFFFFFFFFFF to FFF0000000000001 and 7FF0000000000001 to
| > 7FFFFFFFFFFFFFFF for 64-bit
| > Exhaustive testing would be exhausting, even for 32-bit,
| and I am not sure how to portably create more test values.
| It's really a bit twiddling job for vendors.
| 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
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.
in files isnan*.c for example.
(This might also help serialisation (though I am inclined to the view that
getting quiet_NaN back for all NaNs (preferably signed though I'm also not
fully sure why) is a reasonable expectation for a non-binary serialisation.)
However, perhaps there are other priorities?
-- Paul A Bristow Prizet Farmhouse, Kendal, Cumbria UK LA8 8AB Phone and SMS text +44 1539 561830, Mobile and SMS text +44 7714 330204 mailto: pbristow_at_[hidden] http://www.hetp.u-net.com/index.html http://www.hetp.u-net.com/Paul%20A%20Bristow%20info.html
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk