Re: [boost] Re: Serialization (Persistence) library draft submission

From: Damien Fisher (damien_at_[hidden])
Date: 2002-02-28 22:54:18

On Fri, 1 Mar 2002, rameysb wrote:

> Suppose I write a Computer Aided design package.  I have points, 
> lines in 3D scaling factors and who knows what else.  To save
> and restore a CAD drawing a use a serialization package.  Now
> I port the program to another machine.  I want to be able to
> transfer CAD drawing between machines. In my view if I can't do
> that without writing extra code the whole purpose of using such
> a library is defeated.
> 
> Suppose the two machine have different floating point formats and
> precisions. Machine A uses 80 bits of precision while B uses 64
> bits.  I create a CAD drawing on machine A, serialize (text) to a 
> file, move the file to machine B, run the ported version of the 
> program, deserializee the file and start drawing.
> 
> What has happened here?  Well I lost the 16 least significant bits of 
> precision so the new drawing is slightly in accurate compared to the 
> first.   But wait who is to say the first program was truely accurate 
> to 80 bits in the first place.  Floating point numbers are always 
> approximations of some physical measurement or constant.  What we 
> have done is to convert the CAD drawing from the most suitable 
> representation on machine A to the most suitable representation on 
> machine B.
> 
> So we havn't really transfered the exact object from one machine to 
> another, which is impossible for this example.  

I don't understand what you mean.  It seems to be that it is possible to
transmit an exact version, up to the loss of precision due to the 64 bit
FPU.  How in the world could you do it otherwise?  Serialize and
deserialize to arbitrary-precision integer/floating point types?

Loss of precision is inevitable.  It is up to the programmer to decide
whether it is acceptable or not.  It would be nice if he could indicate to
the library whether to generate an error or simply handle the loss of
precision.

> This is a simple example.  What if we use a stream that has been 
> implemented to read/write to a socket on another machine and we
> don't even know what kind of machine it is? How are we going to 
> address the issue then.

Again, I don't see the problem.  Define a couple of standard types -
64-bit double, 80-bit double (if necessary), 32-bit integer, 64-bit
integer.  Have the logic implemented on both sides in a safe manner (eg
consistent endian choice).

If one platform cannot efficiently support a certain type, then it is up
to the programmer to decide how to handle this.

> Portability and utility demands the numbers be in some sort of 
> canonical form.  I chose text rendition numbers as that canical form.

But you will have exactly the same problems.  If you serialize an 80-bit
double to text, what is the deserializer on a machine with 64-bit doubles
supposed to do?

> Why did I choose this one?  Well its the first that came to mind but 
> there is a real reason.  This permits us to leverage on the 
> float/text conversion functions already programmed for streams in the 
> standard library. What is the point of writing our own?  Are they 
> going to be better than the ones in the standard library? are they 
> going to be faster? use much less space? more robust? I doubt it. 

Use less space, yes, because we can store them in a binary format.

> At the grave risk of letting this subject go off on to a major 
> tangent, I'm going to say I hope no one writes and says - I've got to 
> save all 80 bits of precision on my floating point numbers.  A 32 bit 
> mantissa gives an precision of one part in 4 billion.  I doubt any 
> physical quantities are know with that precision. A 64 bit mantissa 
> gives a precision of 16 ? (someone help me out here) I KNOW no 
> physical quantity is known that precisely.  If you're concerned about 
> keeping only 64 or 32 bits of precision, think about what the numbers 
> truely represent.  If you want to respond to this comment maybe you 
> would like to start another thread.

I don't think this is off-topic.  It seems to be the problem is currently
under-specified.