7

It has been asserted that (even accounting for byte endian-ness) IEEE754 floating point is not guaranteed to be exchangeable between platforms.

So:

  • Why, theoretically, is IEEE floating point not exchangeable between platforms?
  • Are any of these concerns valid for modern hardware platforms (e.g. i686, x64, arm)?

If the concerns are valid, can you please demonstrate an example where this is the case (C or C++ is preferred)?

Motivation: Several GPS manufacturers exchange their binary formats for (e.g.) latitude, longitude and raw data in "IEEE-754 compliant floating point values". So, I don't have control to choose a text format or other "portable" format. Hence, my question has to when the differences may or may not occur.

Community
  • 1
  • 1
Damien
  • 785
  • 3
  • 8
  • 18
  • 1
    Is it that floating point has exchange issues given the many variant FP implementations? IEEE-754 is extraordinarily well precisely defined. – chux - Reinstate Monica Oct 14 '13 at 00:34
  • 4
    I agree with @chux here, I think you are misreading the following sentence from the question you link to: "The ieee754 layout for double is not standard on all architectures." It doesn't mean that there are different representations of IEEE754, it merely means that some architectures are not using IEEE754. – us2012 Oct 14 '13 at 00:44
  • I'm guessing there are some subtleties to do with NaNs and/or sub-normal values and the like. See [Wikipedia](http://en.wikipedia.org/wiki/IEEE_floating_point#Interchange_formats): "As with IEEE 754-1985, there is some flexibility in the encoding of signaling NaN." Hence the question. – Damien Oct 14 '13 at 01:33
  • A text format would be a whole other can of worms. It is often not even guaranteed that parsing a stringified float that was stringified by the same library will parse back to the original float (for example, [this](http://www.exploringbinary.com/incorrect-round-trip-conversions-in-visual-c-plus-plus/)), let alone cross-library/platform. – harold Oct 14 '13 at 14:24

1 Answers1

7

IEEE 754 clause 3.4 specifies binary interchange format encodings. Given a floating-point format (below), the interchange format puts the sign bit in the most significant bit, biased exponent bits in the next most significant bits, and the significand encoding in the least significant bits. A mapping from bits to bytes is not specified, so a system could use little-endian, big-endian, or other ordering.

Clause 3.6 specifies format parameters for various format widths, including 64-bit binary, for which there is one sign bit, 11 exponent field bits, and 52 significand field bits. This clause also specifies the exponent bias.

Clauses 3.3 and 3.4 specify the data represented by this format.

So, to interchange IEEE-754 floating-point data, it seems systems need only to agree on two things: which format to use (e.g., 64-bit binary) and how to get the bits back and forth (e.g., how to map bits to bytes for writing to a file or a network message).

Eric Postpischil
  • 195,579
  • 13
  • 168
  • 312
  • So, based on 3.6: *Interchange formats support the exchange of floating-point data between implementations.* So, is the "interchange format" what is stored in memory and thus what we normally associate as a "double"? Or is it a distinct separate representation? (For example, is it something like the x87 FPU where it is 80-bits internally, but when a value is retrieved, it is a 64-bit value conformant with the "interchange format"?) – Damien Oct 14 '13 at 23:11
  • 3
    @Damien: The language allows for the possibility that a system will use a different format internally. For example, it might store a significand with an explicit leading bit instead of implicit, and it might use separate bits to flag NaNs and infinities. However, I am unaware of any system in which a normal store of an IEEE-754 64-bit binary value to memory does not produce the usual interchange format. The Intel extended format is not the IEEE-754 64-bit format; it is a custom-Intel format. The instruction to store it in 64-bit format is a conversion between types, not a mere format change. – Eric Postpischil Oct 15 '13 at 01:22