Re: [boost] [serialization] How are floating point values handled?

Subject: Re: [boost] [serialization] How are floating point values handled?
From: John Maddock (john_at_[hidden])
Date: 2013-08-08 04:27:19

>> I would have thought it would be better for the serialization lib to
>> set the stream precision before outputting a primitive type - to
>> std::numeric_limits<T>::max_digits10 (or
>> std::numeric_limits<T>::digits10+2 if max_digits10 is not available).
>> However, I recognize that this is a difficult issue!
>
> lol - thanks for recognising that this is a difficult issue.  It is 
> reported
> on a regular basis.
>
> binary_?archive - no issue.
>
> portable_binary_archives - doesn't support floating point numbers.
>
> text archives - this depends on the std::stream to do the the conversion
> to text and back again.  It uses functions in this class to attempt to
> set the precision to high enough number so that no more information
> is lost than is necessary.  Conversion to text and back again has some
> inherent problems.  Note that these have their root cause in
> the std::stream implementations and design rather than the
> serialization library itself.
>
> a) there is not necessarily a one to one mapping of every ieee 754
> number with a binary mantissa to a decimal representation.
>
> My view is that on who relies on perfect round tripping of a
> floating point number is making a design mistake.  Leave
> aside the fact that it cannot be portable between machines
> with different floating point representations (and precisions).
> It conflicts with what a floating point number really is. It's
> an attempt to capture some continuous value to finite level
> of precision.  It generally represents some physical quantity
> which generally can only be measured to a precision less
> than that which our floating point representation can
> represent.  So I've very suspicious of any program which
> requires perfect round tripping - if our program depends
> on having more precision than that which can actually be
> measured - what can theh program actually mean?

Point taken, however it is technically possible to achieve perfect round 
tripping: which is to say both decimal to binary and binary to decimal 
conversions round to nearest.  It is however hard to achieve, requires 
arbitrary precision arithmetic (yes even for float/double) and isn't what 
all std lib's do: msvc being the main culprit here.

> b) compilers/libraries don't handle NaN in a consistent way so
> handling these is inherently non-portable.
>
> I think I address this by trapping whenever one tries to serialize
> a NaN.  My reasoning was that it was a pain to implement,
> and would be unreliable.  I also feel (and felt) that anyone
> actually trying to do this is making a mistake and should
> think about what he's really doing.  (I caught hell for say
> this - anyone who does this doesn't know what he's doing.
> Maybe it was the way I phrased it - oh well).

It sounds reasonable in most cases - however there are situations when a 
genuine NaN might be required - an example might be where you have a table 
of statistics, and a NaN is used to indicate "no data".

John.