Re: [boost] serialization - NaN, +/Inf and others

From: Paul A Bristow (pbristow_at_[hidden])
Date: 2005-11-17 13:57:16

| -----Original Message-----
| From: boost-bounces_at_[hidden] 
| [mailto:boost-bounces_at_[hidden]] On Behalf Of Robert Ramey
| Sent: 17 November 2005 18:00
| To: boost_at_[hidden]
| 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 [phone], Mobile and SMS text [phone]
mailto: pbristow_at_[hidden]  www.hetp.u-net.com