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

From: Paul A Bristow (pbristow_at_[hidden])
Date: 2006-03-16 06:41:18

| -----Original Message-----
| From: boost-bounces_at_[hidden] 
| [mailto:boost-bounces_at_[hidden]] On Behalf Of John Maddock
| Sent: 16 March 2006 10:28
| To: boost_at_[hidden]
| Subject: Re: [boost] [serialization] 
| Serialisation/deserialisationoffloating-point values
| 
| > but honestly - there must be a bug somewhere (I belive it's in
| > lexical_cast), right? Maybe authors of lexical_cast should add one
| > significant place to the string? If not - then why this 
| won't work? Is
| > it really impossible to avoid losing data in conversions?
| 
| No, as already discussed the problem is that many iostreams 
| libraries do not 
| round trip the binary floating point representation to 
| decimal and back 
| again.  This is technically possible to do (albeit with quite heroic 
| efforts), but apparently std lib vendors don't consider it crucial :-(
| 
| That was why I suggested using the C99 style hex format for 
| floats in the 
| serialisation lib: that format is both portable and readily 
| round-trippable 
| since there's no binary-to-decimal conversion involved (just 
| binary to hex).

Anything that guarantees a round trip MUST be a good.

(Getting output and input right would be even better!  There are papers
which present methods for doing it which claim to be proven correct - but
these are not the methods used for popular implmentations.)

Is a hex fully portable?  It surely just promises to be as close as the FP
representation will allow?  Or should we store the FP representation in the
serialization and only deserialize if it matches exactly?  This sounds a
prudent move to me.

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