Re: [Boost-users] cross-platfrom binary serialization?

From: michal.x.strzelczyk_at_[hidden]
Date: 2008-08-28 06:18:31

IMO the pragmatic approach would be to settle with one fp format and 
implement (more or less trivial) transformation functions to support the 
platforms that don't implement it natively. Picking IEEE754 standard would 
seem fine unless somebody can point out gaps preventing this from being 
able to convey features other formats can. 

Going further, to accommodate the somewhat rare cases where IEEE754 would 
not be the best choice the library could support multiple representations 
and platform-specific transformations between them leaving the choice of 
the FP format used by the archive (which could be modified at any time 
using manipulators) to the programmer.

_
Michal Strzelczyk

Daryle Walker <darylew_at_[hidden]> 
Sent by: boost-users-bounces_at_[hidden]
28/08/2008 10:13
Please respond to
boost-users_at_[hidden]

To
boost-users_at_[hidden]
cc

Subject
Re: [Boost-users] cross-platfrom binary serialization?

On Aug 27, 2008, at 4:38 PM, Bo Peng wrote:

>> I have an alternate suggestion: what about continued fractions? 
>> Turn the
>> floating point value into a list of integers.  This works no 
>> matter what
>> f.p. systems the source and destination use.  You just need a 
>> portable
>> integer serialization format.
>
> Then why cannot we use IEEE745 format for float serialization on 
> all systems?

Because I don't think that the IEEE-754 internal format is as stable 
as you think it is.  (Looking at Wikipedia's entries on IEEE-754 and 
754r, there is a standard conceptual format, but problem is how do 
various implementations carry out the internal bit-wise format.  Room 
for interpretation will doom your plan.)

> 1. If a systems is IEEE745 compatible, serialize float numbers
> directly. This will work 99.9% of the times, and will be very
> efficient.
> 2. If a system is not IEEE745 compatible, to serialize a float number,
> we write the number as 32 or 64 continuous bits, in IEEE745 format, to
> de-serialize a float number, we read the number in IEEE745 formats and
> write in native float format. An intermediate string representation
> can be used for the translations.

The string or "direct" conversions may introduce rounding errors.

> I mean, these continuous IEEE745 bits are equivalent to your "portable
> integer serialization format", but will be much more efficient on
> IEEE745 compatible systems.

Is it worth potentially screwing 0.01% of your customers when you may 
not have to?

-- 
Daryle Walker
Mac, Internet, and Video Game Junkie
darylew AT hotmail DOT com
_______________________________________________
Boost-users mailing list
Boost-users_at_[hidden]
http://lists.boost.org/mailman/listinfo.cgi/boost-users
Generally, this communication is for informational purposes only
and it is not intended as an offer or solicitation for the purchase
or sale of any financial instrument or as an official confirmation
of any transaction. In the event you are receiving the offering
materials attached below related to your interest in hedge funds or
private equity, this communication may be intended as an offer or
solicitation for the purchase or sale of such fund(s).  All market
prices, data and other information are not warranted as to
completeness or accuracy and are subject to change without notice.
Any comments or statements made herein do not necessarily reflect
those of JPMorgan Chase & Co., its subsidiaries and affiliates.
This transmission may contain information that is privileged,
confidential, legally privileged, and/or exempt from disclosure
under applicable law. If you are not the intended recipient, you
are hereby notified that any disclosure, copying, distribution, or
use of the information contained herein (including any reliance
thereon) is STRICTLY PROHIBITED. Although this transmission and any
attachments are believed to be free of any virus or other defect
that might affect any computer system into which it is received and
opened, it is the responsibility of the recipient to ensure that it
is virus free and no responsibility is accepted by JPMorgan Chase &
Co., its subsidiaries and affiliates, as applicable, for any loss
or damage arising in any way from its use. If you received this
transmission in error, please immediately contact the sender and
destroy the material in its entirety, whether in electronic or hard
copy format. Thank you.
Please refer to http://www.jpmorgan.com/pages/disclosures for
disclosures relating to UK legal entities.