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.
I've worked at 3 separate trading firms, each making millions or billions in profit yearly, that just use doubles for prices and cash quantities internally.
Just before you send something on the wire you just make sure you serialize (part of which is rounding) to the appropriate tick size.
Generally speaking tick sizes (cents, valid trade price increments, whatever) are many orders of magnitude greater than any possible calculation error, so rounding to the nearest tick just works
My concern is something fairly boring but important nevertheless: your bills/invoices, receipts, credit/debit notes, contract notes, trial balances, ledgers/statements etc.
Internally, you may use whatever precision/scale you want, and compute using doubles or decimals or integers. But I want to see 100.01 - (37.29 + 41.63) = 100.01 - 78.92 = 21.09 in all of these statements.
sieve · · focus · HN ↗
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.
nly · · focus · HN ↗
Just before you send something on the wire you just make sure you serialize (part of which is rounding) to the appropriate tick size.
Generally speaking tick sizes (cents, valid trade price increments, whatever) are many orders of magnitude greater than any possible calculation error, so rounding to the nearest tick just works
sieve · · focus · HN ↗
Internally, you may use whatever precision/scale you want, and compute using doubles or decimals or integers. But I want to see 100.01 - (37.29 + 41.63) = 100.01 - 78.92 = 21.09 in all of these statements.