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

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

+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

---
Paul A. Bristow,
Prizet Farmhouse, Kendal LA8 8AB  UK
[phone]  07714330204
pbristow_at_[hidden]