Hacker News Reader

Comment by zestyping | Hacker News Reader

I am guessing the author would say that you are supposed to only use integer amounts. Amounts are measured in cents, so $15 is `Dinero({amount: 1500, currency: 'USD'})`.

It is a serious problem that `Dinero({amount: 0.1})` doesn't immediately throw an exception, though—if you design a library that horribly breaks on non-integer inputs, you must reject integer inputs loudly and immediately.

View on HN

How often are fractions of a cent calculated and managed? I always assumed that if you're doing some serious finance work you track into fractions of a penny.

Sure, but using floats is still the wrong way to handle this. Much better to just decide how much accuracy you need and set up your fixed-point system to handle that. Additionally you might want e.g. rationals to handle any rate that multiplies amounts.

IIRC you generally do not; accounting standards tend to expect that every "booking" is rounded, so only some intermediate results can ever be in fractions of a penny. This sometimes results in "adjustment" bookings to ensure that a bunch of deals match the required total, because the rounding introduces a difference - e.g. if you have interest accrual by day and the monthly total interest would be $xx.35, then you might accrue $yy.01 every day and $yy.05 on the last day - but not $yy.01166 every day.

Prices are a different issue, you're likely to have prices that are fractions of a penny; but any inventory valuations (either as stock or sale) would again be rounded after multiplying the price with the item quantity.

Perhaps this could use some integration with a general concept of unit dimensions, distinguishing values that are measured in dollars(cents) and values such as prices that are "dollars/item" and can become "dollars" only when multiplied by number of items.

I was working on a heavily government regulated horseracing/gambling mobile website/webapp maybe 7-8 years ago, and we had to prove every intermediate step of any calculation was done in 1/10,000ths of a cent (or perhaps dollar? It was quite some time ago), and any rounding only ever happened once at the very end. (Where by "prove",they meant "submit the source code" - the "easy" way to get this past the regulators was to have "ten thousandths of a cent" be the base unit of a "custom currency", and only ever convert to dollars/cents in the display code. (Nobody ever questioned the ajax/javascript interaction with the resulting "integer" currency numbers... shudder...)

I get the impression back then they everybody in the gaming/gambling industry did this all the time - to the extent that they knew how to organise source code and name variables and functions so the regulators auditing the code would just rubber stamp it.

(I was not "in the gaming industry", we were just doing a mobile friendly front end, in jQuery Mobile, to run on the hot new Samsung Galaxy S2... Now I think I need to go curl up in a dark corner and cry myself to sleep again... Project. From. Hell...)

The nature of odds would require that. Otherwise how would you calculate 1:3 odds?

Same argument applies to interest rates and many other financial calculations too... The thing I didn't know before that project was that there was a "standard" about how much precision you're required to calculate at. Not that ten thousandths of a cent is necessarily "the right answer", but when the regulators tell you that's the answer it takes a lot of discussion/argument away... (Surely even tenths of a cent would suffice???)

18 decimals "ought to be enough for anybody" in the bitcoin age :)

Good call, will fix.

Reply on news.ycombinator.com