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.
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
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.
s: single absolute a; //a and s occupy the same memory slot.
b: cardinal absolute s2; //b and s2 occupy the same memory slot.
for a:= 0 to $FFFFFFFF do begin
if not(IsNaN(s)) then begin //must exclude NaN to avoid exceptions.
assert(a = b);
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.