| -----Original Message----- | From: boost-bounces@lists.boost.org | [mailto:boost-bounces@lists.boost.org] On Behalf Of Paul A Bristow | Sent: 15 May 2006 10:48 | To: boost@lists.boost.org | 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 +44 1539561830 & SMS, Mobile +44 7714 330204 & SMS