The workings of floats

[Fitz Herbert]

SCJ2 question

 float f=4.0F/3.0F;
System.out.println((f*3.0F)==4.0F); 

This prints true or false?
I would say false as:
4.0/3.0 is a reoccuring number 1.333333333.........
the varialbe f of float type holds a specific number of decimal places,
and so when f is then multiplyed by 3.0F the value will be 3.9999999999999.......... reoccuring and not 4.0F
But when compiled prints true???

[Thomas Paul]

A computer can not store a recurring number so f actually contains 1.3333334. Multiply that by 3 and you get 4.0000002 which rounds to 4.0 because 4.0000002 is beyond the precision of a float.

[Orin Malcolm]

Well said thomas

[Layne Lund]

I don't know whether the exact details given by either answer are the way it actually happens. In fact, I'd bet it depends on the environment you run this in. Two different machines may give two different answers.
The moral of the story is that you should NEVER compare floating point numbers with the == operator. As the above discussions illustrate, round off error makes such a comparison unreliable.

[Thomas Paul]

Originally posted by Layne Lund:
I don't know whether the exact details given by either answer are the way it actually happens. In fact, I'd bet it depends on the environment you run this in. Two different machines may give two different answers.

They should't be different. Java religiously follows the IEE 754 floating point standard for the behaviour of floats and doubles.
This is a pretty good write-up on the standard even if it is by Microsoft:
http://research.microsoft.com/~hollasch/cgindex/coding/ieeefloat.html

[Jim Yingst]

It turns out that yes, 4.0F/3.0F should be exactly the same in any Java implementation - but there are other cases where similar expressions are not so bound. It depends on whether a given expression is considered FP-strict or not. (Any compile-time constant expression is FP-strict). From the JLS:

Within an FP-strict expression, all intermediate values must be elements of the float value set or the double value set, implying that the results of all FP-strict expressions must be those predicted by IEEE 754 arithmetic on operands represented using single and double formats. Within an expression that is not FP-strict, some leeway is granted for an implementation to use an extended exponent range to represent intermediate results; the net effect, roughly speaking, is that a calculation might produce "the correct answer" in situations where exclusive use of the float value set or double value set might result in overflow or underflow.

I'm not sure what would be a good example of an expression that can evaluate differently in a non-FP-strict context. But it seems there's at least a possibility of different results...