Can I expect float variable values that I set from literal constants to be unchanged after assignment to other variables?

Question

If I do something like this:

float a = 1.5f;
float b = a;

void func(float arg)
{
  if (arg == 1.5f) printf("You are teh awresome!");
}

func(b);

Will the text print every time (and on every machine)?

EDIT

I mean, I'm not really sure if the value will pass through the FPU at some point even if I'm not doing any calculations, and if so, whether the FPU will change the binary representation of the value. I've read somewhere that the (approximate) same floating point values can have multiple binary representations in IEEE 754.

Answer 1

It should print every time and on every machine. You're not using the output of any calculation, so there's no reason to assume that the values would change.

One caveat: certain "magic" numbers don't necessarily come from memory. In x86 we have the following instructions:

• FLDZ - load 0.0 into ST(0)
• FLD1 - load 1.0 into ST(0)
• FLD2T - load log2(10) into ST(0)
• FLD2E - load log2(e) into ST(0)
• FLDPI - load pi into ST(0)
• FLDLG2 - load log10(2) into ST(0)
• FLDLN2 - load ln(2) into ST(0)

So if you happen to be comparing with one of these values you may possibly not get the exact same value as the const literal you referenced.

Answer 2

First of all 1.5 can be stored accurately in memory so for this specific value, yes it will always be true.

More generally I think that the inaccuracies only pop up when you're doing computations, if you just store a value even if it doesn't have an accurate IEEE representation it will always be mapped to the same value (so 0.3 == 0.3 even though 0.3 * 3 != 0.9).

Answer 3

Here's a (not quite comprehensive) proof that (at least in GCC) you are guaranteed equality for floating literals.

Python code to generate file:

print """
#include <stdio.h>

int main()
{
"""
import random
chars = "abcdefghijklmnopqrstuvwxyz"
randoms = [str(random.random()) for _ in xrange(26)]
for c, r in zip(chars, randoms):
    print "float %s = %sf;" % (c, r)

for c, r in zip(chars, randoms):
    print r'if (%s != %sf) { printf("Error!\n"); }' % (c,r)

print """
    return 0;
}
"""

Snippet of generated file:

#include <stdio.h>

int main()
{

float a = 0.199698325654f;
float b = 0.402517512357f;
float c = 0.700489844438f;
float d = 0.699640984356f;
if (a != 0.199698325654f) { printf("Error!\n"); }
if (b != 0.402517512357f) { printf("Error!\n"); }
if (c != 0.700489844438f) { printf("Error!\n"); }
if (d != 0.699640984356f) { printf("Error!\n"); }

    return 0;
}

And running it correctly does not print anything to the screen:

$ ./a.out 
$

But here's the catch: if you don't put the literal f after the floats in the check for equality, it will fail every time! You can leave the literal f out of the assignment, though, without problems.

Answer 4

If it passes the FPU on one point in time it could be due to optimizations and register handling by the compiler that you end up comparing a FPU register with a value from the memory. The first one may have a higher precision as the latter one and so the comparison gives you a false. This may vary depending on compiler, compiler options and the platform you run on.

Answer 5

I don't think it will behave equal:

float f1 = .1; 
// compiled as
//// 64-bits literal into EAX:EBX


if( f1 == .1 ) 
//// load .1 into 80 bits of FPU register 1
//// copy EAX:EBX into FPU register 2 (leaving alone the last 16 bits)
//// call FPU compare instruction
////

When the compiler generates code as mentioned above, the condition will never be true: 16 bits will be different when comparing the 64bits version of .1 with it's 80bits version.

Concluding: no: you cannot guarantee equality on each and every machine with this code.

Answer 6

In the example, the value 1.5F has an exact representation in IEEE 754 (and pretty much any other conceivable binary or decimal floating point representation), so the answer is almost certainly going to be yes. However, there is no guarantee, and there could be compilers which do not manage to achieve the result.

If you change the value to one without an exact binary representation, such as 5.1F, the result is far from guaranteed.

Way, way, way back in their excellent classic book "The Elements of Programming Style", Kernighan & Plauger said:

A wise programmer once said, "Floating point numbers are like sand piles; every time you move one, you lose a little sand and you pick up a little dirt". And after a few computations, things can get pretty dirty.

(It's one of two phrases in the book that I highlighted many years ago¹.)

They also observe:

• 10.0 times 0.1 is hardly ever 1.0.
• Don't compare floating point numbers just for equality

Those observations were made in 1978 (for the second edition), but are still fundamentally valid today.

If the question is viewed at its most extremely restricted scope, you may be OK. If the question is varied very much, you are more likely to be bitten than not, and you'll probably be bitten sooner rather later.

---

¹ The other highlighted phrase is (minus bullets):

• the subroutine call permits us to summarize the irregularities in the argument list [...]
• [t]he subroutine itself summarizes the regularities of the code [...]

Answer 7

I took a look at the disassembly from the VS2005 compiler. When running this simple program, I found that after float f=.1;, the condition f==.1 resulted in .... FALSE.

EDIT - this was due to the comparand being a double. When using a float literal (i.e. .1f), the comparison resulted in TRUE. This also holds when comparing double variables with double literals.

I added the source code and disassembly here:

  float f=.1f;
0041363E  fld         dword ptr [__real@3dcccccd (415764h)] 
00413644  fstp        dword ptr [f] 

  double d=.1;
00413647  fld         qword ptr [__real@3fb999999999999a (415748h)] 
0041364D  fstp        qword ptr [d] 

  bool ffequal = f == .1f;
00413650  fld         dword ptr [f] 
00413653  fcomp       qword ptr [__real@3fb99999a0000000 (415758h)] 
00413659  fnstsw      ax   
0041365B  test        ah,44h 
0041365E  jp          main+4Ch (41366Ch) 
00413660  mov         dword ptr [ebp-0F8h],1 
0041366A  jmp         main+56h (413676h) 
0041366C  mov         dword ptr [ebp-0F8h],0 
00413676  mov         al,byte ptr [ebp-0F8h] 
0041367C  mov         byte ptr [fequal],al 
// here, ffequal is true

  bool dfequal = d == .1f;
0041367F  fld         qword ptr [__real@3fb99999a0000000 (415758h)] 
00413685  fcomp       qword ptr [d] 
00413688  fnstsw      ax   
0041368A  test        ah,44h 
0041368D  jp          main+7Bh (41369Bh) 
0041368F  mov         dword ptr [ebp-0F8h],1 
00413699  jmp         main+85h (4136A5h) 
0041369B  mov         dword ptr [ebp-0F8h],0 
004136A5  mov         al,byte ptr [ebp-0F8h] 
004136AB  mov         byte ptr [dequal],al 
// here, dfequal is false.

  bool ddequal = d == .1;
004136AE  fld         qword ptr [__real@3fb999999999999a (415748h)] 
004136B4  fcomp       qword ptr [d] 
004136B7  fnstsw      ax   
004136B9  test        ah,44h 
004136BC  jp          main+0AAh (4136CAh) 
004136BE  mov         dword ptr [ebp-104h],1 
004136C8  jmp         main+0B4h (4136D4h) 
004136CA  mov         dword ptr [ebp-104h],0 
004136D4  mov         al,byte ptr [ebp-104h] 
004136DA  mov         byte ptr [ddequal],al 
// ddequal is true