Find a real life example of floating point error - php

Question

The usual advice to handle money and other decimal numbers where accuracy is crucial is to either use integers or strings (plus arbitrary precision libraries) and it makes sense if you understand how floating point maths work. However, I don't have at hand any specific example to illustrate this, as every wrong calculation I've spot in the wild was due to some other mistake: naive comparisons using ==, lack of proper rounding when displaying results, blatantly wrong logic (e.g. calculating taxes with an inconsistent algorithm that also doesn't work on paper)... I've done some research and results either only apply to C/C++ (float/double having different precision) or were mere elaborations on why you can't trust two floats to be equal.
Can you share a self-contained PHP code snippet with carefully selected floating point figures and a correct algorithm that renders an incorrect result explicitly caused by floating point limitations?
Disclaimer: I don't intend to argue, refute or debunk anything, I honestly need an example for my toolbelt.

Answer 1

Things can break fairly easy with much less than a billion iterations. The thing is, by using floats and arithmetic you can very easily find yourself with unexpected results, and even if numbers superficially look fine, the subtle imprecisions can lead to an application bugging out.
Let's try a variation of the example in your answer:
$total = 0.0;
for ($i = 0; $i < 10; $i++) {
$total += 0.1;
}
echo "added ten cents, ten times\n";
// since we added 0.1 € x 10 times, we now have 1€ in total, right?
if ($total == 1) {
echo "I have 1€. All is good in the realm.";
}
else {
echo "WTF? Where is my money? I only have {$total}€!!!!\n";
echo "\$total holds: ";
var_dump($total);
}
The output for the above is:
added ten cents
WTF? Where is my money? I only have 1€!!!!
$total holds: float(1)
Even if $total appears to be float(1), the code follow the 'wrong' branch of execution, breaking our application.
If we execute the same code in PHP8 (beta so far), you'll an easier to understand result:
added ten cents
WTF? Where is my money? I only have 1€!!!!
$total holds: float(0.9999999999999999)
Another simple example:
$balance = 50.03;
$debit = 45.42;
$expected_balance = 4.61;
$real_balance = $balance - $debit;
if ($real_balance !== $expected_balance) {
echo "problems: ";
var_dump($real_balance);
}
The output for the above is:
balance mismatch: float(4.61)
or, in PHP8:
balance mismatch: float(4.609999999999999)
Either of the above examples show that practically, using floating numbers to do (specifically) money arithmetic can be problematic. Since the results no longer match your expectations, not only it can lead to plainly wrong results, but the subtle different results can make the whole application behaving in unexpected ways.
Examples and results, here.

Answer 2

echo floor((0.1 + 0.7) * 10);
Expected result: 0.1 + 0.7 = 0.8; 0.8 * 10 = 8;
Result: 7
Tested on PHP 7.2.12

Answer 3

The question makes little sense because that isn't how floating point errors work.
Inaccuracies are tiny. They happen in remote decimals and they're only noticeable when you require very high precision levels. After all, IEEE 754 powers a vast majority of computer systems and it offers an excellent precision. To put it in context, 0.1 kilometres expressed as float is 0.100000001490116119384765625, what makes accurate up to 1/10 of a µm
if I didn't get maths wrong.
There probably isn't a set of carefully chosen figures and a real-life calculation you'd be expected to use PHP for (an invoice, a stock exchange index...) that renders incorrect results no matter how careful you are with precision levels. Because that's not the problem.
The problem with floating point maths is that it forces you to be extremely careful on every step and it makes it very easy for bugs to slip in.
For applications where accuracy matters, you can write correct software using floats, but it won't be as easy, maintainable or robust.
Original answer:
This is the best I've got so far (thanks to chtz for the hint):
// Set-up and display settings (shouldn't affect internal calculations or final result)
set_time_limit(0);
ini_set('precision', -1);
// Expected accuracy: 2 decimal positions
$total = 0;
for ($i = 0; $i < 1e9; $i++) {
$total += 0.01;
// It's important to NOT round inside the loop, e.g.: $total = round($total + 0.01, 2);
}
var_dump($total, number_format($total, 2));
float(9999999.825158669)
string(12) "9,999,999.83" // Correct value would be "10,000,000.00"
Unfortunately, it relies on the accumulation of a very large number of precision errors (it needs around 1,000,000,000 of them to happen and it needs more than 4 minutes to run in my PC), so it isn't as real-life as I would have liked, but it certainly illustrates the underlying issue.