Hacker News Reader

Comment by recursive | Hacker News Reader

This library has some huge hazards.

    let added = Dinero({ amount: 0.1 }).add(Dinero({ amount: 0.2 }))
    let result = added.equalsTo(Dinero({ amount: 0.3 }))

`result` is false! I can't believe there's a currency library that doesn't do correct decimal arithmetic.

https://codepen.io/recursive/pen/VXogvN?editors=0010

View on HN

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.

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.

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???)

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.

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

Good call, will fix.

The amounts must be specified in cents, as floats can’t be relied upon to perform calculations. That was my #1 reason to design the library using solely integers. I wrote all about it here: https://frontstuff.io/how-to-handle-monetary-values-in-javas...

By "cents", you really mean "minor currency unit" I assume?

In British Pounds, it would be pennies for example.

The doc doesn't explain how the library deals with the various different minor units out there (I've been bitten too many times by code that assumes that all currencies have a minor unit and that 100 minor units = 1 major unit so I'm careful these days).

For example, what about currencies that have a minor unit that's not effectively used in practice or that don't have a minor unit at all (e.g. JPY)? Are the amount supposed to be expressed in this unused / non-existent minor unit?

What happens with currencies that use a subdivision other than 100 for their minor unit (e.g. KWD)? Will the calculations and formatting be correct?

A cent is a minor currency unit; think procent, aka hundred in latin, or used in common international form one-hundreth.

The Kuwaiti Dinar (KWD) the parent mentioned is subdivided into 1000s, not 100s.

But there's no way to do so in JavaScript unless you implement a numeric type by hand, something that Dinero does not do.

In JavaScript every number is a IEEE754 floating point number, and removing decimal places will not change its representation in memory or its limitations.

The only situation when a JavaScript Number type is treated as an integer is a vendor specific optimization for small integers (e.g: Smi in v8).

You can still run into issues such as absorption problems if dealing with only "integers". e.g:

    > 1e16 -1
    10000000000000000 // wrong
    > 1e16 -2
    9999999999999998
    > 1e16 -3
    9999999999999996 // wrong
    > 1e16 -4
    9999999999999996
    > 1e16 -5
    9999999999999996 // wrong
    > 1e16 -6
    9999999999999994
    > 1e16 -7
    9999999999999992 // wrong

But this is just the beginning.

But there's no way to do so in JavaScript unless you implement a numeric type by hand

This is not true: with 64-bit floating-point numbers, calculations on numbers in a range from Number.MIN_SAFE_INTEGER (2^53-1) to Number.MAX_SAFE_INTEGER (-2^53-1) are safe to do. If you go outside this range, the numbers are no longer exact, so you'll have to check for overflow, but it's the same when you use native machine integer types (e.g. uint64) in most languages that have them.

The only situation when a JavaScript Number type is treated as an integer is a vendor specific optimization for small integers (e.g: Smi in v8).

A number is integer if it doesn't have a fractional component regardless of how it's represented by a computer.

There are also operations in JavaScript that treat their inputs as 32-bit integers (numbers are taken modulo 2^32), such as bitwise operations and Math.imul. But if you don't use them, integers can be as large or as small as described above.

Some numbers do not have an exact representation in IEEE754. This leads to problems such as:

    > 1.03 - 0.42
    0.6100000000000001

These are not integers! Integers are exactly represented from -2^53-1 to 2^53-1.

You claim that as long as numbers fit in a double precision IEEE754 floating point number significand, which is what JS implements, you are safe. Fine.

But what happens after successive operations? the risk increases. Is this a good idea when dealing with currency? No. Does this library warn you about those cases or throw an error? no. Does this library provide unit tests for those cases? no.

I agree that this library doesn't looks good — a proper implementation would use a better precision (e.g. 1/10000 of a currency unit) rather than "cents" (1/100), and of course, check ranges and the absence of fractions (Number.isSafeInteger).

You may have designed it using only integers, but it's very easy to use it with non-integers, which will result in hard-to-diagnose errors. It should probably throw if a non-integer is encountered. Failing that, a huge blinking red banner at the top of the docs should explain the problem.

Annnnd that's why I like types :D

I've read the post and I do get the point BUT we currently support 25 languages, use accounting.js (I know, it's just formatting) and the backend returns float values and we still get by. I'm aware of the risks and not happy about it, but probably good will and magic holds it together (plus backend has a veto over the price with the final, canonical value on their side).

Would it be possible to rewrite this library to use "floatish" numbers with initial multiplication and flooring then using decimal.js? I understand that non-internal arithmetics are slow as hell, but most of the time people just add products to a cart or sometimes apply a percentage discount.

On the other hand, please do throw for non-integer values :)

It's not (solely) an issue of speed.

http://weitz.de/ieee/

Plug in 0.11 and 0.1 and click `+`. You expect 0.21, but since 1/10 isn't cleanly represented in base 2 using a finite number of bits... (just like 1/3 isn't cleanly represented in base 10 ~0.33..).

And when it comes to currency, rounding and "good enough" is probably not going to be good enough.

It may be totally silly (I consider myself lucky for getting by with good enough so far:)), but would `(Math.floor(0.11x10xx2)+Math.floor(0.1x10xx2))` divided by 100 work?

Probably I'd like to do the last step with a custom arithmetic and not store the final value as a float, but like I said, I'm not sure. I get that the lowest denominator route is good, but it feels complicated and the chance of migrating a shoddy "good enough" project is zero in that case.

(For fuck's sake, in 2018 formatting text or using utf8 on hacker news is too much to ask for, it's even worse than slashdot)

I don't know enough of IEEE 754, but I don't think binary representation of numbers are guaranteed to be strictly greater i.e. I think you at least want Math.round instead of Math.floor.

It might be fine, depending on the use case. I think dealing with any complicated currency arithmetic and throwing floating point arithmetic on top is throwing gas on a fire.

That said, I consider this to be similar to the phone number representation. As in, what is the correct way to store and manipulate a phone number? 1 555 555 5555 looks a lot like a number, but does it make sense to increment by 1 or divide by 5?

Similarly, $1.12 looks a lot like a float, but would you ever have $pi? In practice currency acts more like an integer with possibly infinite digits i.e. probably a candidate for something like Java's BigInteger. But that's just my $0.02 :)

A third alternative is to directly store values in cents, relative to the unit. If you need to store 10 cents, you won’t store 0.1 nor 10, but 100.

I'm missing something here? Do you mean you're storing mills (₥)?

Simple typo, fixed :)

Do you have any suggestions on how to deal with money where you need more precision then cents? For example financials and inventory markets?

If you can find an atomic amount, (e.g. PicoDollars) I'd suggest using that. Javascript doesn't have an infinite precision integer type.

In cases where that isn't possible, try an infinite precision javascript library. https://github.com/MikeMcl/big.js

You could _probably_ find a way to shim big.js into OP's library :)

Basically, you store everything as integers.You can specify whatever precision you want, just by saying x digits are before the decimal. E.g. 1.234566 is 1234566. Rounding when needed(just be consistent), but you never round until the last step which is when you're going to be displaying/storing the final value.

On the other hand, it has 100% coverage and zero vulnerabilities! We really should teach people how to test properly and not just use metrics to sell a library :-(.

I think the inability to write effective tests is single biggest contributor to technical debt over the past decade. Ineffective tests are arguably more dangerous than no tests at all, due to what you pointed out: the "100% Coverage" banner is about as effective as those Verisign website seals that were so popular in the early 2000s.

Unit test coverage calcify your code. People will resist change because "it breaks unit tests".

The best are acceptance tests. But here the use of SaaS systems with no sandbox or locally deployable mocks mean this is hard to automate.

Like the Stripe model, amounts should be in cents (integers), don't use decimals.

Functions such as allocate() are super useful:

    // returns an array of two Dinero objects
    // the first one with an amount of 502
    // the second one with an amount of 501
    Dinero({ amount: 1003 }).allocate([50, 50])

I assume you're supposed to use a smaller denomination of your choice to avoid decimals. For example, the submitted page tells you to use cents for EUR values and there's presumably nothing that prevents you from using tenths or hundreths of cents as the base denomination if you want.

Perhaps it should not allow you to create an instance with a non-integral `amount` ?

Reply on news.ycombinator.com