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

31–40 of 115 posts

Re: How to Handle Monetary Values in JavaScript

#31

Post by zie »

reaperducer wrote: post #18

Banking apps, e-commerce websites, stock exchange platforms, we interact with money daily. We also increasingly rely on technology to handle ours. Yet, there’s no consensus around how to programmatically handle monetary values. I wonder if the average person would find this frightening.

IBM has had a solution for a long time: http://speleotrove.com/decimal/decarith.html

Python uses it: https://docs.python.org/3.5/library/decimal.html

Just because JS is stupid doesn't mean other languages are.

Re: How to Handle Monetary Values in JavaScript

#32

Post by jczhang »

rtkwe wrote: post #24

> Floats: 0.1 + 0.2 // returns 0.30000000000000004 The question is how much of an issue is this really? How often is 4 parts in 10 quadrillion a meaningful error when dealing with money? Especially when most of the time JS is dealing with money it will be presentation.

Yeah seriously. You'll have some front-end lib func converting that to 2 significant digits right of the decimal anyway. Weak argument imo haha.

Re: How to Handle Monetary Values in JavaScript

#33

Post by strainer »

sk5t wrote: post #21
strainer wrote: post #15

Earlier quoted context omitted.

I think the advantage behind using something like Big.js is to future proof the code against hyper-inflation. Though a dedicated currency engine would better have the ability to set and conveniently update the currency denomination of stored values to cope with this. With float64's maximum 'safe' integer at almost ten thousand trillion, I believe this should be enough to compute most commercial transactions securely…

This approach, at least in languages like C and Java, would effectively smush the effective MAX_INT down to MAX_INT/1e15 or whatever. No bueno.

It doesn't because basically - the point floats. The max_int doesn't mean the largest whole number that can be represented, it effectively means how much resolution you have on the number line in every one of a very wide range of scales. These languages all give exactly the same standard IEEE754 float math results for basic operations.

Re: How to Handle Monetary Values in JavaScript

#34

Post by tikhonj »

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

Rational numbers don't lose precision, but the compromise is that they can get arbitrarily large after a series of calculations, even if the calculations themselves involve small numbers.

Having access to rational numbers is great and there are times they are incredibly useful, but I don't think it's a good default.

Re: How to Handle Monetary Values in JavaScript

#35

Post by john_of_peaches »

rtkwe wrote: post #24

> Floats: 0.1 + 0.2 // returns 0.30000000000000004 The question is how much of an issue is this really? How often is 4 parts in 10 quadrillion a meaningful error when dealing with money? Especially when most of the time JS is dealing with money it will be presentation.

Because value !== 0.3 and that can cause unexpected problems on the edges (which are the worst kind of issues).

Re: How to Handle Monetary Values in JavaScript

#36

Post by maxxxxx »

aaaaaaaaaab wrote: post #22
maxxxxx wrote: post #5

Earlier quoted context omitted.

You can't model 1.0 correctly but it will be something like 1.000006667. If you add enough of these numbers you will be off.

Integers can be represented exactly in IEEE754.

How about 2.1?

According to this https://www.h-schmidt.net/FloatConverter/IEEE754.html

2.1 will be represented as 2.099999904632568359375

Re: How to Handle Monetary Values in JavaScript

#37

Post by mjevans »

Equally important to choosing a valid numeric type to store the data is solid business logic to handle it.

In the contrived example of splitting a value of 999.99 among more than one payment, the correct solution is:

    * Determine the next payment based on the current balance.
    * Invoice/Apply/Etc that payment
    * Repeat until there is a balance of 0 (zero).

Re: How to Handle Monetary Values in JavaScript

#38

Post by kickopotomus »

rpeden wrote: post #26
reaperducer wrote: post #18

Banking apps, e-commerce websites, stock exchange platforms, we interact with money daily. We also increasingly rely on technology to handle ours. Yet, there’s no consensus around how to programmatically handle monetary values. I wonder if the average person would find this frightening.

I don't think it's true that there's no consensus around how to programatically handle monetary values. Maybe there's no consensus around how to do it in JavaScript. In the Java world, there's JSR-354: https://jcp.org/en/jsr/detail?id=354 Cobol has handled money well for decades. .NET has Decimal, which should handle money correctly as long as you're working with values less than 79.2 octillion. In my part of the wor…

Exactly correct. More stuff than most people expect is still handled by COBOL. I haven't worked with a bank in a few years, but back in 2015 the one I was at was attempting to migrate a lot of the COBOL tasks to Java.

Re: How to Handle Monetary Values in JavaScript

#39

Post by noselasd »

aaaaaaaaaab wrote: post #22
maxxxxx wrote: post #5

Earlier quoted context omitted.

You can't model 1.0 correctly but it will be something like 1.000006667. If you add enough of these numbers you will be off.

Integers can be represented exactly in IEEE754.

Not all of them, e.g. 9007199254740993 can't be represented in a double precision format (what javascript uses)

For single precision floats you start having issues representing integers as low as 16777217

Re: How to Handle Monetary Values in JavaScript

#40

Post by noselasd »

maxxxxx wrote: post #36
aaaaaaaaaab wrote: post #22

Earlier quoted context omitted.

Integers can be represented exactly in IEEE754.

How about 2.1? According to this https://www.h-schmidt.net/FloatConverter/IEEE754.html 2.1 will be represented as 2.099999904632568359375

well, 2.1 isn't an integer.
Post reply on HN