> Many people know that you shouldn’t do decimal calculations, such as those involving U.S. dollars and cents, with the floating-point numbers in most programming languages. This is because decimal numbers can’t be expressed exactly as such floating-point numbers, so you will encounter rounding errors.
Why not, rounding to the nearest cent is going to be much less precise for any realistic amount of dollars when using 64 bit floats (the type of float Javascript uses in every browser).
I think there’s an implicit assumption with this sort of “use a special decimal type” advice: that the rules of the transactions are defined in terms of decimal rounding.
I mean, just as an example, your savings account interest could be computed continuously, e^(rt), which would obviously be better approximated in floating point than some decimal type. But they won’t have to do any approximation if they write the contract so that the value compounds nightly and is rounded to the nearest, whatever, tenth of a cent (which means that the rounding isn’t an approximation at all, it is part of the definition of the value being represented).
amelius · · focus · HN ↗
Why not, rounding to the nearest cent is going to be much less precise for any realistic amount of dollars when using 64 bit floats (the type of float Javascript uses in every browser).
bee_rider · · focus · HN ↗
I mean, just as an example, your savings account interest could be computed continuously, e^(rt), which would obviously be better approximated in floating point than some decimal type. But they won’t have to do any approximation if they write the contract so that the value compounds nightly and is rounded to the nearest, whatever, tenth of a cent (which means that the rounding isn’t an approximation at all, it is part of the definition of the value being represented).