Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How to Handle Monetary Values in JavaScript

frontstuff.io

Post reply on HN
Print view View original

91–100 of 115 posts

Re: How to Handle Monetary Values in JavaScript

#91

Post by tigershark »

stephengillie wrote: post #78
smallnamespace wrote: post #77

Earlier quoted context omitted.

I'm curious to hear about your specifics, since I was at a shop where front office used all floats (doubles). Not sure what the back office did, but I doubt it was all done in arbitrary position arithmetic. Note that if an accountant says things need to be accurate down to the penny, that's probably an exaggeration [1]. Financial statements are typically rounded to the thousands, e.g. Intel's are rounded to million […

Collecting the rounding leftovers into another bank account was the plot of Office Space.

Also superman 3 15 years before...

Re: How to Handle Monetary Values in JavaScript

#92

Post by kchoudhu »

zachrose wrote: post #81
diNgUrAndI wrote: post #65

Earlier quoted context omitted.

How would you deal with exchange rate, which changes in real time?

In the lazy version i have suggested, the exchange rates are deferred until you “need to know” and the sum is converted into a concrete currency. If you’re keeping these values around in memory for an extended period of time time and you care about rapid changes to exchange rates, then you have a complex domain and the deferred exchanges may or may not be a good fit, but at that point you need larger system design, n…

You need a timestamp and a timeseries database of exchange rates so that you can go back in time and reconstruct your calculations at a latter date as well.

Source: worked at a bank that implemented pretty much this.

Re: How to Handle Monetary Values in JavaScript

#93

Post by haberman »

smallnamespace wrote: post #83
kbenson wrote: post #82

Earlier quoted context omitted.

If you bill customers for anything, and there are multiple items being totaled on an invoice, you do not want that total to be anything except an accurate sum of the individual parts. At a minimum, you look like a rinky dink operation that doesn't know how to add dollars and cents. On the other end of the spectrum, some people will likely accuse you of theft, and not nicely. Do not fall under the assumption that the…

I think that's the disconnect here — 'high' finance is not an exact science, and clients don't actually have an easy way of checking the numbers directly themselves — not only the models, but the inputs are also proprietary. Even auditors and regulators are dependent on bank models. Note that the article's advice is to use their own library, but the library just uses JS floats as ints and a separate precision arg: ht…

> This doesn't give you any more precision than using floats directly, just a wider 'mantissa' range.

I think this analysis misses a deep and important point. The library you linked uses decimal floating point (in software) instead of the binary floating point used by IEEE floats.

The point of this is not to increase overall precision. A double is already precise to 2e-14% of its value, which means it's capable of representing something like $1 Trillion before it will get off by a whole cent.

The point of using decimal floating point is that it can exactly represent the values we care about when dealing with currency. This allows us to have no error, instead of trying to keep our error small. It means we never have to round (unless performing division).

You could have 1000x the precision in binary floating point, and decimal floating point would still be better for money.

Re: How to Handle Monetary Values in JavaScript

#94

Post by LoSboccacc »

smallnamespace wrote: post #77
projectileboy wrote: post #72

Maybe it’s just that I’ve done a few gigs at financial institutions, but it’s pretty shocking to see the number of people in this thread arguing that it’s a-ok to use floating point for money. I don’t want to get dragged down into specifics, but if you’re doing this, please, please don’t. Money is one of those things like dates and times - everyone who hasn’t done much of it can’t figure out what all the fuss is abou…

I'm curious to hear about your specifics, since I was at a shop where front office used all floats (doubles). Not sure what the back office did, but I doubt it was all done in arbitrary position arithmetic. Note that if an accountant says things need to be accurate down to the penny, that's probably an exaggeration [1]. Financial statements are typically rounded to the thousands, e.g. Intel's are rounded to million […

I've worked with a bank at a fund management application and money is annoying in surprising ways.

Some background: funds can handle fractional quotes and each fund can have its own rounding rules, funds mixes can handle fractional percentages, when money enters or leaves the system it gets rounded to cents because you can't move fraction of cents (unless digital)

So, you get issues even using arbitrary precision math.

Operation order matters. Rounding impacts everywhere so you need to be consistent across the business logic, reversing an operation need to have rounding applied in a specific order to result in the final date to match the initial.

Order is also important when splitting money, because the last share gets all the leftover cents that come from rounding the previous shares split so that the total gets allocated fully. I.e. moving the last 1$ from one fund mix to another mix that has 3 equally divided fund is going to round as .33 movement toward each, but you can't just leave that cent on the previous fund mix and you can't just drop it going nobody notices, so one of them gets .34

Re: How to Handle Monetary Values in JavaScript

#95

Post by bschwindHN »

Handling currency in JavaScript just sounds like a bad idea. It's better to be using a language with a type system that has your back on this kind of thing, and preferably to deal with monetary values as rational numbers.

There's a good article on this subject here:

https://ren.zone/articles/safe-money

Re: How to Handle Monetary Values in JavaScript

#96

Post by b2ccb2 »

ed_balls wrote: post #42
b2ccb2 wrote: post #4

I really like the approach Perl 6 takes with FatRat[1]. You basically have an object which holds a numerator and denominator, so all arithmetic calculations do not loose precision. [1] https://docs.perl6.org/type/FatRat

Floating point arithmetics is not the only problem. See bankers rounding.

Yes, but bankers rounding should be the last step in calculation, not an intermediate.

Re: How to Handle Monetary Values in JavaScript

#97

Post by swish_bob »

kchoudhu wrote: post #92
zachrose wrote: post #81

Earlier quoted context omitted.

In the lazy version i have suggested, the exchange rates are deferred until you “need to know” and the sum is converted into a concrete currency. If you’re keeping these values around in memory for an extended period of time time and you care about rapid changes to exchange rates, then you have a complex domain and the deferred exchanges may or may not be a good fit, but at that point you need larger system design, n…

You need a timestamp and a timeseries database of exchange rates so that you can go back in time and reconstruct your calculations at a latter date as well. Source: worked at a bank that implemented pretty much this.

To multiple different currencies at multiple valuation points. With optional exchange rate costs. It's a pain in the arse ...

Source: worked on multi-currency fund tracking software.

Re: How to Handle Monetary Values in JavaScript

#98

Post by swish_bob »

btilly wrote: post #61
smallnamespace wrote: post #58

> Using floats to store monetary values is a bad idea This is waay overstating the case, it very much depends on whether getting the exact answer down to the penny matters to you. Worked for a few years at a large investment bank, everything was done in floats because the modeling error of your derivatives pricers would be much larger than the roundoff error, but floats were much more convenient to develop with and f…

And I had the misfortune for working for a few years with bond modeling software that used floats internally. Turns out that the first thing a financial analyst does to compare two implementations of a bond securitization model is to look at the pennies. If those tie out, then you're good. But if your software predicts money off by a dime in a billion dollar model deal, the analyst WILL notice and WILL try to get to…

They need some way to validate things, and it turns out if the number isn't exactly the same when they run their samples they don't trust any of them. For at least some value of them.

The founder at the last place I worked at was famously difficult to satisfy because of this. You couldn't even begin to talk about how you were presenting data to him unless you were absolutely sure the numbers in your mockup were correct. He just couldn't see past an "incorrect" value when dealing with faked data ...

Re: How to Handle Monetary Values in JavaScript

#99

Post by village-idiot »

zie wrote: post #76
empyrical wrote: post #48

Really excited to see what possibilities for number handling native BigInt in JavaScript will bring https://developers.google.com/web/updates/2018/05/bigint

probably none. To handle currency correctly you have to handle rounding to the nearest penny correctly. Computers absolutely SUCK at this, in general. So you need a Decimal library, that can handle decimal numbers. Integers ARE NOT DECIMAL . IBM has had a solution for a long time: http://speleotrove.com/decimal/ Python uses it: https://docs.python.org/3.5/library/decimal.html Get a proper decimal library, and then yo…

You can also just use the smallest unit and work in cents. The Stripe API does this instead of dealing with decimals.

Re: How to Handle Monetary Values in JavaScript

#100

Post by village-idiot »

zachrose wrote: post #81
diNgUrAndI wrote: post #65

Earlier quoted context omitted.

How would you deal with exchange rate, which changes in real time?

In the lazy version i have suggested, the exchange rates are deferred until you “need to know” and the sum is converted into a concrete currency. If you’re keeping these values around in memory for an extended period of time time and you care about rapid changes to exchange rates, then you have a complex domain and the deferred exchanges may or may not be a good fit, but at that point you need larger system design, n…

I’d rather keep the IO call to determine exchange rate far away from my arithmetic, personally.

This technique is fantastic for units that don’t change relations though, like mass and length.

Post reply on HN