Boost logo

Boost :

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".


Boost list run by bdawes at, gregod at, cpdaniel at, john at