-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of Robert Ramey Sent: Thursday, January 10, 2013 4:28 PM To: boost@lists.boost.org Subject: Re: [boost] [serialization] round-trip serialization of float
Adam Lerer wrote:
Note: There's some discussion of this topic in a slightly different context here: http://boost.2283326.n4.nabble.com/serialization-Serialisation-deseria lisation-of-floating-point-values-td2604169i20.html
Remember that the serialization library uses standard i/o for input/output. So this discussion above is actually the same issue.
In general, libraries won't guarentee bit for bit equality. This is due to a number of reasons:
a) not every binary floating number has en exact representation when rendered as decimal.
b) different libraries can't be expected to handle this in all the same way.
c) text type archives are meant to be portable between architectures. So, for example, on can create floating point numbers in an environment which uses an 80 ieee754 representation, write them to a file, and read them on another architecture - say a 64 bit ieee754 representation and expect things to work. That is, the streams i/o attampts to preserve values (rather than bit representation ) to the extent that it makes sense to do so.
d) It gets much worse with floating point values such as NaN - since different libraries differ on how to address this.
e) Remember, this is not a serialization library issue-- but rather one related to floating point numbers and standard i/o. i
So, If you feel you need to preserver the exact set of bits - don't use floating point - use something else.
As the originator of the thread above, I just want to add that I agree with this summary. You can only find out if serialization-deserialization will work by both examination of the bit layouts and careful testing. Your best bet is to use the max_digits10 precision (or, sadly for now, better use the formula given - because on the previous VS version, std::numeric_limits<float>::max_digits10 was wrong :-) and to use scientific format (to avoid a previous VS buglet). Nan and infinity now has a fair chance of working, after work by Johan Rode, but testing is still essential. Good luck! Paul --- Paul A. Bristow, Prizet Farmhouse, Kendal LA8 8AB UK +44 1539 561830 07714330204 pbristow@hetp.u-net.com