Floating point values have a limited precision. Hence a value might
not have the same string representation after any processing. That also
includes writing a floating point value in your script and directly
printing it without any mathematical operations.

If you would like to know more about "floats" and what IEEE
754 is, read this:
http://www.floating-point-gui.de/

Thank you for your interest in PHP.

Rule #1: never compare floats with ==.

Doesn't matter if its == or === always returns false.

Also, the result from the foreach loop is exactly '100' and I'm comparing to 100 , its the same string representation.

I think I'm going to convert both values to strings and them compare them to work around this problem.

convert to strings is sonsense even if it works by luck, limited precision was already explained, the value is something like "100.0000000000000142108547152020037174224853515625"

if(100 == (int)$value)
if(100 === (int)$value)

one of both would work

<?php
$value = 61.8 + 20.1 + 11.4 + 6.7;
ini_set('precision', 1000);
if(100 == (int)$value)
{
 echo "true: $value\n";
}
else
{
 echo "false: $value\n";
}
?>

You should always compare floats with <, >, <= or >=. In your case, make it $value>99.999 and you'll be good.

> You should always compare floats with <, >, <= or >=

for sure not

> In your case, make it $value>99.999 and you'll be good

even not for that isolated case because it would be >= 100 instead == 100 but not "99.9" with a random count of 9 added at the end

what you always should do is be as explicit as you can and > is the exact opposite, properly cast your values before compare and use === and !== where ever you can

You should be checking that the result is within a range that depends on the accuracy of your numbers and what you're doing with them. In this case, adding numbers are accurate to one decimal place means that a result of 100 (strictly, 100.0) could in fact be anything between 99.95 and 100.05. (The real range won't be anywhere near that bad unless you're adding a LOT of numbers—in which case you maybe ought to change scale and work with integers—because the internal representation is much more precise than that.)

But it should be obvious that adding numbers with one-decimal-place accuracy will always produce a sum with one decimal place of accuracy, so any additional "accuracy" than that must therefore be a consequence of the approximations needed to represent all of the numbers involved with a fixed non-decimal precision.)

So in this case, you want to round the sum off two one digit of accuracy and then compare:

round(61.8 + 20.1 + 11.4 + 6.7, 1) == 100.0