Whether assigning of single precision IEEE754 float to double is reversible?

Question

Using the IEEE754 standard, let's assign single precision variable s to double precision variable d and then assign d to single precision variable s'.

Is this operation is reversible (lossless) for any value that can be represented in IEEE754, including NaN, infinity, etc.? In other words, is it guaranteed that s = s' for all possible s?

---

On my processor NaN is not reversible (01 00 80 7f != 01 00 c0 7f). Brute force shows that NaN is not reversible, but this might be implementation dependent, so please answer within the scope of IEEE754 standard.

Answer 1

The value of a number does not change when converting a single to a double.
This includes converting single +/-inf to double +/-inf.

However the printed representation of that number may change, this is the way that number would be printed on screen or converted to a string. Let me give you an example.

single s;
single s1;
s = 125.32f;
println("value of s = " + s);  --> displays 125.32
double d = s;
println("value of d = " + d);  --> displays 125.31999969482422  

Does that mean that s ≠ d?
No: s does equal d, and when d is assigned to s1, s and s1 will be exactly equal.
The difference in the displayed value is because more digits are needed to uniquely distinguish the argument value from adjacent values of the same type.
This is a quote from the Java docs, but of course this issue extends to all languages that use IEEE754 floats.

Full disclosure: I copied most of this answer from: https://stackoverflow.com/questions/17504833/why-converting-from-float-to-double-changes-the-value

See here if you want to hear it from Jon Skeet himself: https://stackoverflow.com/questions/17504833/why-converting-from-float-to-double-changes-the-value

Update
I just tested the assertion using the following code and I can indeed confirm that casting a single to a double and back again does not yield any data loss whatsoever. This was tested in Delphi, but I have no reason to suspect the results would be different in any other IEEE754 compliant environment.

var
  a: cardinal;
  s: single absolute a;     //a and s occupy the same memory slot.
  s2: single;
  b: cardinal absolute s2;  //b and s2 occupy the same memory slot.
  d: double;

begin
  for a:= 0 to $FFFFFFFF do begin
    if not(IsNaN(s)) then begin  //must exclude NaN to avoid exceptions.
      d:= s;
      s2:= d;
      assert(a = b);
    end;
  end;
end.

The test took 2 minutes of CPU time.

Just to satisfy the OP's curiosity there is no 'algorithm' happening here, the line d:= s is compiled as:

Project82.dpr.20: d:= s;
00419526 D905CC0E4200     fld dword ptr [$00420ecc]
0041952C DD1DD80E4200     fstp qword ptr [$00420ed8]

That means the CPU itself performs the cast. And I do believe we can trust the CPU to be IEEE754 compliant.

Answer 2

Maybe this will help. This is not full answer - just information to think.

5.3 Floating-Point Format Conversions It shall be possible to convert floating-point numbers between all supported formats. If the conversion is to a narrower precision, the result shall be rounded as specified in Section 4. Conversion to a wider precision is exact.

IEEE Std 754-1985

Answer 3

Quite funny, I wasn't able to find the IEEE 754 document that describes the standard. I guess that such conversions are not part of the "formal" standard, and they are left to the implementation (I may be wrong here).

Information-wise, there is no reason to lose information by the conversion 32bit->64bit->32bit. If performed correctly, the conversion should return exactly the original value.

Checking a few edge cases (using the calculators of http://babbage.cs.qc.cuny.edu/IEEE-754.old/64bit.html) show this is indeed the case. It shouldn't be too difficult to write a program that goes over all the 32bit values and verifies they convert back correctly. Ignoring the NaNs, this shouldn't even take that long.