71–80 of 115 posts
Earlier quoted context omitted.
Sorry, picked the wrong number. But I think the general idea is correct.
I am pretty sure you were thinking of 0.1 which, indeed, requires an infinite number of digits to be represented in binary (like 1/3 in decimal).
Earlier quoted context omitted.
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 .
For monetary values, though, the denominators should be the same. This means that the denominator won't get arbitrarily large. For serious uses of rationals you need to have control over when the top and bottom are divided by the GCD. For currency you want to keep the denominator at 100. 50/100 wants to remain as that and not get simplified to 1/2.
A while back I did some exhaustive testing of several ways to calculate sales tax on a sale in Python3 and JavaScript, testing the various "obvious" ways against all tax rates in increments of 0.0001 from 0.0000 to 1.0000 and all sale amount from 0.00 to something like 25.00. It was interesting. Here are some simple cases to try. One or more of these break most of the seemingly obvious approaches: 1% of $21.50 3% of…
> 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.
Really excited to see what possibilities for number handling native BigInt in JavaScript will bring https://developers.google.com/web/updates/2018/05/bigint
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 you can devote brain cells to actual problems. The IBM link above includes links to libraries that do it right.
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…
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 [2].
The IRS also lets you round off dollars [3].
I agree though that if you're building a large complex system with many coders, and either 1) nobody has a full view of the calculation and can do the numerical analysis or 2) there's a high chance that at some point in the future you need penny-accurate bookkeeping, then it's safer to use a very wide int or float type.
Of course, there's also the case where the accountant or auditor doesn't actually need penny precision, but it's easier to just tell the coder 'just in case'.
[1] https://www.accountingtools.com/articles/2017/5/14/the-mater...
[2] https://s21.q4cdn.com/600692695/files/doc_financials/2017/an...
[3] https://taxmap.irs.gov/taxmap/pub17/p17-006.htm#TXMP5d034bfb
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 […
> 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…
I really want to be generous here: I think your experience is very isolated. I have family that is executive level at a Wall Street bank, they would have you fired over the superfluous loss of a dollar, much less a few thousand dollars because that type of rounding error can end up in the millions over the course of a year if you deal 100+ million dollar transactions 5-6 times a day. Here's how it would go: "Why are…
I think we're talking past each other a bit.
Financial products pricers themselves only have as much precision as the inputs, which in many cases might only have 3-5 significant figures. Using arbitrary precision math doesn't buy you any more precision than what your inputs have.
Remember that a 64-bit float gives you 52 bits ~ 14 decimal digits of precision, so unless you're doing something that has terrible numerical stability, the error of your model assumptions and inputs will always dominate floating point error. It doesn't matter if your model spits out $XXXXXX.08 or $XXXXXX.15 - both answers are essentially the same.
Just to provide context, we were pricing deals with notional amounts in the billions and PVs up to tens of millions.
Note that we're comfortable doing nuclear bomb simulations or climate models using FP64 floating point calculations, for the same reasons — the error in your model is bigger anyway.
> they would have you fired over the superfluous loss of a dollar
The handling of customer accounts is different at a bank since you're not supposed to be creating or losing money out of thin air—that's the Fed's job.
But that's not what the article claims—it claims that any monetary amount, anywhere, should never use a float, which IMO overstates things from both a business and maths standpoint.