Re: [boost] [serialization] Serialisation/deserialisationoffloating-point values

From: Paul A Bristow (pbristow_at_[hidden])
Date: 2006-03-16 05:34:48

| -----Original Message-----
| From: boost-bounces_at_[hidden] 
| [mailto:boost-bounces_at_[hidden]] On Behalf Of Caleb Epstein
| Sent: 15 March 2006 23:20
| To: boost_at_[hidden]
| Subject: Re: [boost] [serialization] 
| Serialisation/deserialisationoffloating-point values
| 
| On 3/15/06, Janek Kozicki <janek_listy_at_[hidden]> wrote:
| >
| >
| > try following modifications in above code. If you still get 
| a mistake by
| > one bit, then .... well, I'd be very surprised.
| 
| 
| Prepare to be suprised.
| 
| Here's the exact code I compiled:
| 
| #include <iostream>
| #include <sstream>
| #include <cassert>
| #include <boost/lexical_cast.hpp>
| 
| int main ()
| {
|     std::stringstream stream;
|     double orig_value = 0.0019075645054089487;
|     stream << boost::lexical_cast<std::string> (orig_value);
|     double num = boost::lexical_cast<double> (stream.str());
|     assert (num == orig_value);
| }
| 
| On gcc + Linux this fails:
| 
| lc: lc.cpp:12: int main(): Assertion `num == orig_value' failed.
| 
| Breakpoint 1, main () at lc.cpp:12
| 12          assert (num == orig_value);
| (gdb) print num
| $3 = 0.0019075645054089489
| (gdb) print orig_value
| $4 = 0.0019075645054089487
| 
| On MSVC 8, the program also asserts and the values are 
| similarly mismatched:
| 
|         orig_value    0.0019075645054089487    double
|         num    0.0019075645054089489    double
| 
| Note that boost::lexical_cast uses a precision of
| std::numeric_limits<T>::digits10
| + 1 in its T-to-string conversions.  For double, this is 16 
| which would
| probably explain the mismatch on the 17th significant digit 
| on two separate
| platforms.

Well I have pointed this mistake out over two years ago, but it still hasn't
been changed.  I have to say I think that this is a bit poor.  Our testing
of this very widely used utility is also not up to Boost standards either.

Sadly though, I fear this is not the only problem.  I think that there is
also a problem in the Microsoft input string to double, even with enough
decimal digits, for a small proportion of decimal digits strings. There
testing / quality aspriation is obviously not brilliant either. I may get
round to checking this out more fully later.

Paul

-- 
Paul A Bristow
Prizet Farmhouse, Kendal, Cumbria UK LA8 8AB
Phone and SMS text [phone], Mobile and SMS text [phone]
mailto: pbristow_at_[hidden]  http://www.hetp.u-net.com/index.html
http://www.hetp.u-net.com/Paul%20A%20Bristow%20info.html