UPDATE 14:22: Thanks to @eddm and @thatdavidmiller this is not a bug! But it is something that PHP programmers should be aware of (and, embarrassingly, as an ex-assembler coder myself (Z80 and MC68000) I should have already known the answer. Explanation below.
Try executing the following line of code:
printf( "%d", (0.58*100));It's pretty clear you should get the result 58. But I get 57! I tweeted this earlier today and got a couple of my followers reporting the same anomaly. Thanks to @Jldb and @JimAnning for corroboration here and here.
The problem appears even if 0.58 is the value of a variable, and the bug can prove highly embarrassing for instance when important values need to be from a database and rendered accurately to screen.
There are workarounds, like using "%s" or "%f", but "%d" *should* work!
PHP attempts to hide the binary element of computing from its users, but inevitably values end up being stored as binary. Non-integer numbers are stored as floating point values.
Due to the fundamental way CPUs store decimal data, not every value has an exact corresponding floating point value. This allows a very wide range of values, from tiny to huge, to be represented by a limited number of binary bits. When an exact value is not available, the nearest floating point value is used.
So back to the "bug". 0.58 is not an integer, so it must be stored as a floating point value. The nearest available is actually 0.5799999...
0.5799999... * 100 is 57.99999...
When trying to display 57.99999... as decimal, the printf formatter quite correctly strips the decimal point and gives... 57!.
Lesson: don't use printf("%d") on anything other than basic integers.