| -----Original Message----- | From: boost-bounces@lists.boost.org | [mailto:boost-bounces@lists.boost.org] On Behalf Of Robert Ramey | Sent: 17 November 2005 18:00 | To: boost@lists.boost.org | Subject: [boost] serialization - NaN, +/Inf and others | | Troy S. and I have been looking at the question of implementing | serialization | of NaN, +/-Inf for floats, and doubles for portable text or | binary archives. | | Turns out there's a fly in the ointment. | | For determining if a given double contains a "special" value, float.h | contains the following handy function | | int _fpclass( | double x | ); | | which returns one of the following values: | | _FPCLASS_SNAN Signaling NaN | _FPCLASS_QNAN Quiet NaN | _FPCLASS_NINF Negative infinity ( -INF) | _FPCLASS_NN Negative normalized non-zero | _FPCLASS_ND Negative denormalized | _FPCLASS_NZ Negative zero ( - 0) | _FPCLASS_PZ Positive 0 (+0) | _FPCLASS_PD Positive denormalized | _FPCLASS_PN Positive normalized non-zero | _FPCLASS_PINF Positive infinity (+INF) | | | So we could write a flag to the archive indicating if its a | special value. | | So far, so good. | | When the archive is read back, we can read the flag and initialize | the variable with the appropriate value. | | BUT - I can't find any "official" to initialize a | float/double to any of | these | values. They seem to be the result of operations and its certainly | not obvious that all compilers would be on the same page here. | | Note that this same problem arises whenever a float/double is | written/read | to/from a stream in a way designed to be portable. So it | must have come | up before. What's the solution here? | | Robert Ramey Dinkumware says that C99 math.h (to be added to C++ by TR1) provides fpclassify #define fpclassify(x) <int rvalue> [added with C99, int functions in C++] The generic-function macro accepts an rvalue argument x of some real floating-point type and evaluates to: * FP_INFINITE for an argument that is positive or negative infinity * FP_NAN for an argument that is not-a-number (NaN) * FP_NORMAL for an argument that is finite and normalized * FP_SUBNORMAL for an argument that is finite and denormalized * FP_ZERO for an argument that is positive or negative zero or possibly some other implementation-defined value. But of course their VALUES are not specified in the standard. C Macros for INFINITY, NAN are provided (in C99 if not alrady) and will probably be used to implement the C++ functions which return std::numeric-limits<floating-pointType>::NaN() and ::quiet_NaN(). But you need to know the floating-point type of course. Denormalised probably don't need to be treated any differently. For hardware that doesn't deal with denormalised (VAX/ALPHA?) can't be portable anyway? The positive and negative infinties and zeros really are different in representation in MS world at least, but I fear you may just have to ignore that. http://www2.open-std.org/JTC1/SC22/WG14/www/C99RationaleV5.10.pdf does not provide any rationale for the lack of sign on infinity and zero. Getting -zero is unlikely to be a problem, but getting +infinity instead of -infinity could be most confusing - as different as you can get ;-) I suspect C99 put it in the 'too difficult' box? HTH Paul -- 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@hetp.u-net.com www.hetp.u-net.com