3 ms·

I use to think like that, but then there's practice over theory : 1/ When a coder thinks about writing "if a <= b", then he writes "if a <= b", he easily forge

by wiz21 11y ago

I use to think like that, but then there's practice over theory : 1/ When a coder thinks about writing "if a <= b", then he writes "if a <= b", he easily forgets that he should write "if a <= b + epsilon()" 2/ When people are faced with "I have to have this number with 2 decimals", they sometimes write a = round(a * 100)/100; forgetting that 'a' is a float (or double), and then they completely forget that the new 'a' is just not accurate. 3/ Issues with floats arise on simple operations such as addition. And people tend to think that simple operations have no rounding issues. It'd be perfectly valid to work with floating point for money; but then you have to take care of the rounding issues much more often than with fixed point (or BigDecimal if you're in the java world). Once you use those BigDecimal, addition becomes safe, and "manual" rounding works as expected (when you round to 2 decimals, you get exactly 2, not an approximation). So, after project managing several teams of developers, I can safely say that although F.P. can be fine, most people can't handle the mental load of thinking about rounding issues on each math operation they do (and "most people" includes myself). That's a human risk management issue, not a theoritical one.

krylon 11y ago
> 1/ When a coder thinks about writing "if a <= b", then he writes "if a <= b", he easily forgets that he should write "if a <= b + epsilon()" So true! In a previous job, I had to work with code that did computational geometry, and I quickly learnt that lesson the hard way. I shared an office with my supervisor, who spent a lot of time on the phone, so I also learnt not to curse like a sailor, a lesson I appreciate, in retrospect, almost as much.
Asbostos 11y ago
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.
kazinator 11y ago
> I use to think like that, Like what? > When people are faced with "I have to have this number with 2 decimals", they sometimes write a = round(a * 100)/100; forgetting that 'a' is a float (or double), and then they completely forget that the new 'a' is just not accurate. This is in fact perfectly accurate when decimal floating point is used. "float" and "double" aren't decmal, are they. But I repeat myself. For round() you could even have some decimal-based rounding like banker's. > Issues with floats arise on simple operations such as addition. Not when they are decimal, repeating myself again.

by wiz21 11y ago

krylon 11y ago

> 1/ When a coder thinks about writing "if a <= b", then he writes "if a <= b", he easily forgets that he should write "if a <= b + epsilon()" So true! In a previous job, I had to work with code that did computational geometry, and I quickly learnt that lesson the hard way. I shared an office with my supervisor, who spent a lot of time on the phone, so I also learnt not to curse like a sailor, a lesson I appreciate, in retrospect, almost as much.

Asbostos 11y ago

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.

kazinator 11y ago

> I use to think like that, Like what? > When people are faced with "I have to have this number with 2 decimals", they sometimes write a = round(a * 100)/100; forgetting that 'a' is a float (or double), and then they completely forget that the new 'a' is just not accurate. This is in fact perfectly accurate when decimal floating point is used. "float" and "double" aren't decmal, are they. But I repeat myself. For round() you could even have some decimal-based rounding like banker's. > Issues with floats arise on simple operations such as addition. Not when they are decimal, repeating myself again.