Subject: Re: [boost] [serialization] How are floating point values handled?
From: Paul A. Bristow (pbristow_at_[hidden])
Date: 2013-08-08 05:16:09
> -----Original Message-----
> From: Boost [mailto:boost-bounces_at_[hidden]] On Behalf Of John Maddock
> Sent: Thursday, August 08, 2013 9:27 AM
> To: boost_at_[hidden]
> Subject: Re: [boost] [serialization] How are floating point values handled?
> >> 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
> 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
+1 for NaN - and for infinity
In Boost.Math it has proved very useful to properly support these two types - and they are
'Standard' in numeric_limits.
Johan Rade's facets for Facets for Floating-Point Infinities and NaNs shows that I/O for this can be
done - and is portable for all platforms that support them (all the popular ones).
Whereas the layout in 64-bit doubles of IEEE754 layout is pretty standard for X86 and ARM chips, the
output of infinity and NaN isn't - but using the above facets it can be fixed.
So I think this is should be the objective for serialization too.
--- Paul A. Bristow, Prizet Farmhouse, Kendal LA8 8AB UK +44 1539 561830 07714330204 pbristow_at_[hidden]
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk