Hacker News Reader

Comment by sieve | Hacker News Reader

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.

View on HN

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.

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.

Actually 128 int uses 2 times the storage for less dynamic range. I agree however that for financial applications int is always better. You don't want float dynamic range on finance calculations

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.

When implementing currency with integers, actually with fixed-point numbers, there is no difficulty in having an exchange rate with the same precision as the integer format, i.e. up to 18-19 digits for 64-bit integers.

You just have to implement the conversion function carefully, i.e. the exchange ratio would actually be represented not by a single number, but by a ratio of suitable integers, to ensure no loss of precision during the conversion done by exact multiplication with extended double-word result and then division.

I like using rational types for that sort of thing.

Reply on news.ycombinator.com