Besides Python’s fractions, there are also constructive reals, exemplified by Android calculator where you can swipe any answer to get as many digits as you want.
Accounting has the concept of materiality. But you still want the figures to tally to the last cent.
One way to do this is to separate the computation/storage and presentation layer: use integers to store values as cents for computation/storage and only convert to dollars+cents on display. But then someone might suddenly demand three digits after the decimal point and you cannot go about changing every stored value just because the logic changed in one part of the application. So, using decimals is the safer choice.
I prefer integers for my plain text ledger software though because the format is in my control.
> 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).
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.
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.
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.
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 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.
> 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.
Decimals or pennies, you still have rounding errors. For example, if your contract is $100 / year. You will get the full $100 if you bill yearly, quarterly, or semi-annually. But if you bill monthly, no matter if you deal in pennies or fractional dollars, the sum total of your invoices for the year will be less than $100.
One way to do this is to separate the computation/storage and presentation layer: use integers to store values as cents for computation/storage and only convert to dollars+cents on display. But then someone might suddenly demand three digits after the decimal point and you cannot go about changing every stored value just because the logic changed in one part of the application. So, using decimals is the safer choice.
I prefer integers for my plain text ledger software though because the format is in my control.
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).
They use binary fixed-point numbers/integers, where such computations are exact, while not having the huge computational overhead of decimal floating-point numbers.
The article's images clearly show the rounding error mess your get without decimals.
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.
Decimals or pennies, you still have rounding errors. For example, if your contract is $100 / year. You will get the full $100 if you bill yearly, quarterly, or semi-annually. But if you bill monthly, no matter if you deal in pennies or fractional dollars, the sum total of your invoices for the year will be less than $100.