Re: Serialization (Persistence) library draft submission

From: rameysb (ramey_at_[hidden])
Date: 2002-02-28 22:29:36

--- In boost_at_y..., "Noah Stein" <noah_at_v...> wrote:

> > It strikes me that this is a problem with serialization to text-
based
> > files anyway.  I mean, if you serialize a 64-bit integer to a 
file and
> > then deserialize it on a 32-bit platform with no "long long" 
or "__int64",
> > what are you going to do?  So the issue is the same regardless of 
whether
> > we are talking about text or binary, IMHO.
> 
> My personal feeling is that serializing back a 64-bit integer on a 
different
> platform that does not support a 64-bit integer is really a non-
issue.  If
> the data type is not supported, what does it matter that you can't 
serialize
> it back?  If you think you can work around not being able to get 
data out,
> why was it saved in the first place?  And if you need a 64-bit 
integer on a
> platform that doesn't have one, implement one, then you can 
serlialize it
> back.
> 
> 
> -- Noah

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 maintain that this is what we really want to do - How could it be 
otherwise?  Why would we want to do any other thing.

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.

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

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. 

I'm willing concede that there may be some special cases where we 
want to save/recover a binary stream and I've agreed to add in that 
capability.  But nothing will convince me that are any thing but 
that - special cases.

The concept of storing objects should be independent of 
implementation peculiarities.   In our CAD example, our interest is 
the drawing and the program to manipulated it.  The actual bits are 
only the means to this end.

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.

Robert Ramey