Epsilons are almost worse than the floating point errors they try to solve! Now you have to work out a safe epsilon that'll always work and you create even more

Epsilons are almost worse than the floating point errors they try to solve! Now you have to work out a safe epsilon that'll always work and you create even more edge cases. A lot of the programming I do involved numbers that the user inputs, so I can't hard code an epsilon because they might enter 1e-10 and break it. Luckily though, a lot of algorithms and formulas can be reformulated so they either don't do = comparisons or if they do, it doesn't matter which case comes out when the two operands are very similar. I think of floating point numbers as being good for representing real world quantities - things you can measure with an instrument. It never matters if you read 1.2999999999993 instead of 1.3 because every practical instrument is less accurate than that anyway. If you start needing to test for equality, that's a sign something's wrong in your design. You can never measure two lengths with a ruler in real life and check if they're equal. So maybe you should be using integers instead, or maybe you don't really need equality. Your point 3 about rounding issues with addition disappears if you think of the value as being a physical measurement. You just don't care about those errors because they are always insignificant. Isn't the problem with floats for money more a problem with the conventions of accountants? By rounding everything to 2 decimal places, they're obviously creating far more error than double precision's ~16 places. They just tolerate their specific type of error by convention.