-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Robert Ramey Sent: 30 December 2007 18:59 To: boost@lists.boost.org Subject: Re: [boost] A question regarding serialization lib
Paul A Bristow wrote:
The chances of this a very small 1 in 3 values of a very narrow range-
I disagree with this. I don't think the chances are very small.
This is not conjecture - it was an observed behaviour as my original report shows. It only emerged by accident - and was only confirmed by a random sampling of round-tripping values. My understanding was that other compilers did NOT show this problem.
only MS is known to have this problem
I don't think it's isolated to microsoft. I think it's an inherent limitation of trying to represent some binary fractions exactly as decimal fractions.
I am confident from my investigation that it is failure to provide the *nearest* representable floating-point value from a decimal digit string - but, bizarrely, only in a very small region, (IIRC from 0.0001 to 0.0005). With this (as is provided by the C++ *compiler* standard when 'reading' decimal digit strings into floating-points like float, double & long double), you can round-trip to decimal digit strings and back - provided of course that you use enough decimal digits. But there is no similar requirement on reading with std:: iostreams, perhaps surprisingly (I think the authors assumed it but didn't think to specify it). (Of course, you can only expect 'round-tripping' to work if the floating point format is the same). The same applies to lexical_cast. So an answer to the first question: probably - but if the floating-point types differ, then all float-point value 'round-tripped' will be a few bits wrong, and you might get a tiny proportion wrong for the reasons in my original (rejected) report to Microsoft. Paul --- Paul A Bristow Prizet Farmhouse, Kendal, Cumbria UK LA8 8AB +44 1539561830 & SMS, Mobile +44 7714 330204 & SMS pbristow@hetp.u-net.com