41–50 of 115 posts
As others have noted, if you're doing any kind of math that involves floating point numbers and you will displaying them to a user, you'll almost certainly want something like this.
While it's not specifically a "Money" class it can form an excellent base for one.
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
Earlier quoted context omitted.
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
I know you knew what I meant.
While reading, I thought "hang on, what about non-decimal currencies?" but it turns out that is no longer a concern for modern usages: https://en.wikipedia.org/wiki/Non-decimal_currency
You can implement a correct set of fraction manipulation functions in well under 100 lines of code with a bit of algebra. It seems likely there are several well-tested high-performance fraction libraries for JavaScript. They should be tiny.
Some people in the UK apparently voted to leave the EU so that they could have a blue passport [0], perhaps there are some who also hope we return to imperial measurements and pounds, shillings and pence. I'm quite sure that even in that unlikely event, some programmers will still insist on using floating point numbers for currency.
[0] Although Malta has a blue passport and is in the EU. And the only reason the passports were blue in the first place was to meet an international standardization.
> 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.
I spent 13 years maintaining a 2mloc reservation and accounting system that used floats for everything. By the time I got there and understood enough it was simply too late to do anything about it.
Just say no, really; that road leads to madness.
If you need precision; and many do; consider fixnums, rationals or bignums, in order of increasing complexity and flexibility.
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.
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).
Earlier quoted context omitted.
Your details are off. 1.0 is precisely representable in double precision floating point with no error.
Sorry, picked the wrong number. But I think the general idea is correct.