Re: [boost] Stream input and output of NaN and infinity

From: Paul A Bristow (pbristow_at_[hidden])
Date: 2006-05-17 10:34:02

|  -----Original Message-----
|  From: boost-bounces_at_[hidden] 
|  [mailto:boost-bounces_at_[hidden]] On Behalf Of Paul A Bristow
|  Sent: 15 May 2006 10:48
|  To: boost_at_[hidden]
|  Subject: [boost] Stream input and output of NaN and infinity

Whooow! Steady on chaps!

I had hoped this might not trigger a concerted Boosters attempt to cure all
the faults in floating-point arithmetic, IEEE754, mathematics, C++, world
poverty ...

But sadly I was wrong ;-((

Plese can we go back to the original problem which was highlighted by
Boost.Serialization:

1  At present, if you serialize a floating-point type value which happens to
be NaN or infinite, you probably don't get any warning on output (MSVC
1.#QNAN), and worse still you may get an apparently correct but misleading
input on 'restoring' the archive (MSVC 1.).

You CAN rely on the behaviour being seriously different on different
platforms (VisualAge will restore' quiet_NaN).

So unless you check every floating-point value for finite-ness before
'output' to an archive (and you only **ever** serialise finites), you are
taking a significant risk.

2  You may wish to handle values that are 'missing' or 'defective in some
way': using NaN is a convenient way to achieve that, albeit with meanings
that must be private to your application.  If you don't have some
floating-point representation to indicate 'NotAValue', you are in danger of
going back to Dark Age programs that said "enter 999999 to end input".

3  You may wish to handle + and/or - infinity.

This proposal is an attempt to:

1  Reduce the risk of not detecting not-finites (especially in
round-tripping to streams).

2  Allow some application-dependent, but otherwise portable, way of handling
'missing' or 'defective in some way' values usng NaN.

3  Allow some portable way of handling infinity values.

4  Make UserDefined Floating-point Types more useful.

It assumes C++/C99 Standards:

isfinite, isnan, isinf and numeric_limits<FPtype>::quiet_NaN() and
infinity().

(And that they work!)

It also seems reasonable and pragmatically useful to assume that all
floating-point values have a sign bit, and that it can be determined by
signbit.  This is necessary to permit + and - infinity, and so I feel it may
have some use to permit a tiny bit more information about a NaN to allow
+NaN and -NaN.  There is no pretence to any mathematical meaning - only that
applications can make use of this bit in any way they chose, and that it
will be portable between OSes (but not necessarily other applications).

For example, suppose that one wishes to distinguish between 'missing' values
- no data input by the user, and values that have produced a NaN by some
mal-computation.  One could, for example, chose to signal 'missing' with
-NaN and 'bad' with +NaN.

(If the IEEE754 revision eventually is concluded, an implementation is free
to use information from the fuller NaN format, provided the OS can decipher
it.  My guess is that most won't and KISS is the best policy.  I am not sure
I understand the revision 

http://754r.ucbtest.org/drafts/754r.pdf - Latest IEEE754 draft

But I don't see it prohibiting a precceding sign bit to "NAN"?)

Please can you tell me if you think my pragmatic proposal (now in version 2)
meets these limited objectives.

Thanks

Paul

PS Please can anyone advise me what GCC does with output - AND INPUT - of
NaN and infinity?

---
Paul A Bristow
Prizet Farmhouse, Kendal, Cumbria UK LA8 8AB
[phone] & SMS, Mobile [phone] & SMS