Question

I have a simple PHP program called "PuraPuraNanya":

$a     = 100;
$b     = 3;
$test1 = $a/ $b;
$test2 = 33.333333333333;  // $test2 == $test1

var_dump(($test1 * $b));   // float(100)
var_dump(($test2 * $b));   // float(99.999999999999)

Any explanation for that?

Answer 1

100/3 results in 33.3-repeating.

There is no decimal point value that will ever show it. In maths, such a number is normally shown by a little dot over the repeating value. (though I have no idea how to show that in this code box).

Refer to this wiki article to see how they are represented in various places and a much more detailed explanation that I have given here.

However, from the article here is a snippet of the summary:

In arithmetic, repeating decimal is a way of representing a rational number. Thus, a decimal representation of a number is called a repeating decimal (or recurring decimal) if at some point it becomes periodic, that is, if there is some finite sequence of digits that is repeated indefinitely. For example, the decimal representation of 1/3 = 0.3333333… or 0.3 (spoken as “0.3 repeating”, or “0.3 recurring”) becomes periodic just after the decimal point, repeating the single-digit sequence “3” infinitely. A somewhat more complicated example is 3227/555 = 5.8144144144…, where the decimal representation becomes periodic at the second digit after the decimal point, repeating the sequence of digits “144” indefinitely.

Now, that’s the crux of your issue here, but also keep in mind (as the other two answers point out) that floats are amazingly innacurate in terms of calculations and comparisons. A quick search of this site will reveal a small army of people that have had problems with the internal representations of floats – mainly which resulted in unexpected behavior when doing comparisons.

Take a long read of the PHP warning on the float data type – again I have copied the important bit here:

Additionally, rational numbers that are exactly representable as floating point numbers in base 10, like 0.1 or 0.7, do not have an exact representation as floating point numbers in base 2, which is used internally, no matter the size of the mantissa. Hence, they cannot be converted into their internal binary counterparts without a small loss of precision. This can lead to confusing results: for example, floor((0.1+0.7)*10) will usually return 7 instead of the expected 8, since the internal representation will be something like 7.9999999999999991118….