The limitations of floats in PHP

jwagner

Hello,

I'm sure you guys out there are familiar with the limitations of floats. For example, the following code, will show how a float might lead you to loose a whole number.

<?php 
$floaty = (0.1 + 0.7) * 10;  //you would expect this to be a solid 8, right?
echo $floaty . "\n";  // output without conversion - outputs 8 as expected
echo (int)$floaty . "\n";  //output with int conversion - outputs 7!
?>

From what I have read, the reason this outputs 7 when converted to integer is because internally the number is stored as 7.99999999 but my question is why? Why is it stored like that?

If you write the code so that $floaty is 0.8 * 10, you will have no problem. So that means that 0.1 + 0.7 is not the same as 0.8
but why?

Also, why when I write 0.3 * 10 and I echo it to output, I get 3 and not 3.3333333333 as I would have expected?

laserlight

jwagner wrote:
From what I have read, the reason this outputs 7 when converted to integer is because internally the number is stored as 7.99999999 but my question is why? Why is it stored like that?

Suppose I asked you to write down a decimal representation of 1/3. If you do not make use of notation to indicate "repeats forever" (e.g., a dot above the last digit), you might write 0.333333, and perhaps stop there. Now, if I ask you to multiply the number by 3 and truncate to an integer, you might compute 0.333333 * 3 = 0.999999, then truncate that to 0. So, the problem is that you were unable to represent 1/3 in base 10 with a finite amount of space. Likewise, there are numbers that cannot be represented in a binary floating point representation, so they have to be approximated, resulting in inaccuracy.

=jwagner wrote:
If you write the code so that $floaty is 0.8 * 10, you will have no problem. So that means that 0.1 + 0.7 is not the same as 0.8
but why?

It may be the case that what was actually stored for 0.8 is different from what was computed with 0.1 and 0.7, since 0.1 and 0.7 would have to be approximated themselves.

jwagner wrote:
Also, why when I write 0.3 * 10 and I echo it to output, I get 3 and not 3.3333333333 as I would have expected?

Why do you expect 3.3333333333 as the result?

Weedpacket

laserlight wrote:
It may be the case that what was actually stored for 0.8 is different from what was computed with 0.1 and 0.7, since 0.1 and 0.7 would have to be approximated themselves.

Yup; 0.8 is represented by a (binary) approximation that is closer to 0.800000000000000044408921 (in other words, the number has been rounded up and the last bit - the 53rd, as it happens - is a "1" when in fact the number continues "01....").

0.1 is stored as 0.100000000000000005551115

and 0.7 as 0.699999999999999955591079 (this time it's been rounded down to fit).

And so what you write as "0.1 + 0.7" is actually computed as 0.100000000000000005551115+0.699999999999999955591079 and whatever that comes out to it has to be less than 0.8000000000000000.

jwagner

Thanks very much to both of you. You explanations have helped me a lot.

Bjom

so....resolved (mark as resolved hint hint)

To make conversions from floats to int more reliably return what you expect, use round on the float. That leads to more "natural" results.

Bjom

jwagner

Bjom;10923025 wrote:
so....resolved (mark as resolved hint hint)

To make conversions from floats to int more reliably return what you expect, use round on the float. That leads to more "natural" results.

Bjom

Now, that's a good tip. Thanks so much.