Re: [Caml-list] Strange behaviour of string_of_float

[Xavier Leroy <Xavier.Leroy@inria.fr>]

>> If you can serialize to binary, you can acheive what you want by
>> serializing the 64 bits integers you get with Int64.bits_of_float and
>> applying Int64.float_of_bits to the integers you deserialize.
>
> Actually, for serialization, I strongly reccommend first using
> classify_float to split off and handle NaNs, Infinities, etc., then
> using frexp to split the float into a fraction and exponent.  The
> exponent is just an int, and the fractional part can be multiplied by,
> say, 2^56 and then converted into an integer.
>
> The advantage of doing things this way, despite it being slightly more
> complicated, is two fold: one, it gaurentees you the ability to recovery
> the exact binary value of the float, and two, it sidesteps a huge number
> of compatibility issues between architectures- IIRC, IEEE 754 specifies
> how many bits have to be used to represent each part of the float, but
> not where they have to be in the word.

The only architecture I know where this problem could occur is the old
(pre-EABI) ABI for ARM, which has "mixed-endian" floats.  But the
implementation of Int64.{bits_of_float,float_of_bits} goes to some
length to rearrange bits as expected, i.e. with the sign bit in the
most significant bit of the int64, followed by the exponent bits,
followed by the mantissa bits in the least significant bits of the
int64.

So, the case analysis on the float that Brian suggests is a bit of an
overkill, and I strongly suggest using the result of
Int64.bits_of_float as the exact, serializable representation of a
Caml float.

- Xavier Leroy