alt Hacker NewsAccounting 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.
Replies
Using 64-bit integers as a count of a hundredth or of a thousandth part of a cent should be enough for most purposes (i.e. up to ten thousand or one hundred thousand billions of $).
If you want to be able to count trillions of trillions of dollars with a resolution of a millionth part of a cent, then you can use 128-bit integers.
Computing exactly with 128-bit integers is many times faster than computing only approximately with decimal floating-point numbers and it requires less memory storage for the same dynamic range.
This gets tricky when it comes to dealing with currency conversion. On my most recent credit card bill, foreign currency transactions show an exchange rate with 10 digits of precision.
I like using rational types for that sort of thing.
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