> 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).
The rounding behavior with true decimals is easy to control and understand across number magnitudes and doesn't suffer from platform specific quirks like floats/doubles.
The article's images clearly show the rounding error mess your get without decimals.
If you're calculating your monthly expenses that's okay, but across millions of transactions of arbitrary amounts, something financial systems do regularly, aggregates start not adding up and you don't know where the money went.
The decimal library worries about rounding, that's basically free. With floats you need to decide when to use rounding (because you don't want to show a balance of -0.000000086) and it's more difficult to use automatic checks for the same reason.
"The nearest cent" is already a bad assumption. Should IEEE 754 representation dictate taxes and money splitting?
You could end up with splitting an account down the middle, and ending up with an extra cent being created out of thin air, or one destroyed. In billions of transactions each day, this could be a problem for balancing books when there is no longer any equality check.
When not using floats, the rules and checks become more… deterministic, if you don't mind stretching the definition of that word a bit.
It’s easier just to use a proper decimal type than to remember all of the ways where using floats will bite you in the ass. The behavior is unintuitive even in trivial examples. Code like
True, but those who do not use decimal floating-point numbers do not use such binary floating-point numbers.
They use binary fixed-point numbers/integers, where such computations are exact, while not having the huge computational overhead of decimal floating-point numbers.
Indeed, though this is platform dependent. Mainframes have strong hardware support for decimal fixed-point arithmetic, making it the preferred representation for fixed-scale business data, though conceptually it's very similar to binary fixed-point.
Decimal floating-point is also hardware-supported, so it doesn’t carry the same computational overhead it does on platforms where it must be implemented in software.
For many years, nobody has supported decimal numbers in hardware, except IBM (the deprecated instructions of Intel 8086 and 8087 do not count).
IBM has done this, despite it being an inferior technical solution, because it binds those who choose it to IBM hardware.
Programming currency operations with decimal floating-point numbers is easier for naive programmers.
Even on IBM mainframes, implementing currency operations using 64-bit or 128-bit integers is much faster and less resource-consuming than with decimal numbers, but the implementation of some of the operations can be a little tricky, when it must be guaranteed that no loss of precision may occur.
I think that I might have seen recently an announcement from someone else than IBM who has introduced hardware support for decimal floating-point numbers, perhaps from Fujitsu. In any case, whoever introduces such hardware support does it to lure some customers to migrate from IBM to them, and not because it were a good solution for implementing operations with money.
I came across this article today, by pure chance, and thought you might enjoy it: <a href="https://cs-syd.eu/posts/2022-08-22-how-to-deal-with-money-in-software" rel="nofollow">https://cs-syd.eu/posts/2022-08-22-how-to-deal-with-money-in...
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).
Regular people understand the decimal system and they understand rounding in that system. The floating point system is a different system that they don't understand. People need to trust that the mechanics of payments are correct or they feel like they're being ripped off, and you can't really trust what you don't understand. Rounding of decimal pennies means that people get payments systems they can trust at the cost of precision. Nobody cares about sometimes being up or sometimes being down a fraction of a penny.
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).
glimshe · · focus · HN ↗
The article's images clearly show the rounding error mess your get without decimals.
amelius · · focus · HN ↗
glimshe · · focus · HN ↗
andreareina · · focus · HN ↗
sobriquet9 · · focus · HN ↗
knorker · · focus · HN ↗
You could end up with splitting an account down the middle, and ending up with an extra cent being created out of thin air, or one destroyed. In billions of transactions each day, this could be a problem for balancing books when there is no longer any equality check.
When not using floats, the rules and checks become more… deterministic, if you don't mind stretching the definition of that word a bit.
sluukkonen · · focus · HN ↗
adrian_b · · focus · HN ↗
They use binary fixed-point numbers/integers, where such computations are exact, while not having the huge computational overhead of decimal floating-point numbers.
OGWhales · · focus · HN ↗
Decimal floating-point is also hardware-supported, so it doesn’t carry the same computational overhead it does on platforms where it must be implemented in software.
adrian_b · · focus · HN ↗
IBM has done this, despite it being an inferior technical solution, because it binds those who choose it to IBM hardware.
Programming currency operations with decimal floating-point numbers is easier for naive programmers.
Even on IBM mainframes, implementing currency operations using 64-bit or 128-bit integers is much faster and less resource-consuming than with decimal numbers, but the implementation of some of the operations can be a little tricky, when it must be guaranteed that no loss of precision may occur.
I think that I might have seen recently an announcement from someone else than IBM who has introduced hardware support for decimal floating-point numbers, perhaps from Fujitsu. In any case, whoever introduces such hardware support does it to lure some customers to migrate from IBM to them, and not because it were a good solution for implementing operations with money.
OGWhales · · focus · HN ↗
[dead]
OGWhales · · focus · HN ↗
AlotOfReading · · focus · HN ↗
Changing representations isn't a substitute for the numerical analysis you should be doing for financial calcs.
vatsachak · · focus · HN ↗
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).
clickety_clack · · focus · HN ↗