Strange behaviour of string_of_float
[
Home
]
[ Index:
by date

by threads
]
[ Message by date: previous  next ] [ Message in thread: previous  next ] [ Thread: previous  next ]
[ Message by date: previous  next ] [ Message in thread: previous  next ] [ Thread: previous  next ]
Date:  20080623 (07:58) 
From:  Xavier Leroy <Xavier.Leroy@i...> 
Subject:  Re: [Camllist] Strange behaviour of string_of_float 
>> 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 (preEABI) ABI for ARM, which has "mixedendian" 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