You can, but you shouldn't. Use of fixed-point numbers is way more reliable, often faster as it's implemented with integer numbers, you can easily detect overflow, you can increase/decrease precision if you need, etc.
Using floating-point numbers for money
11–20 of 128 posts
Re: Using floating-point numbers for money
#12Sorry, but I remain skeptical. The same people who use `float` for financial calculations are probably the same people who don't understand how/why to do the rounding described to avoid these problems. Way too many programmers think that they are working in base 10 when using float. Why not just make them use it, and keep them out of trouble. Also, I wonder what the overhead of rounding every operation is? Comparable…
> I would argue that financial math by definition needs to be accurate to the penny. Where is "pretty close" financial calculations considered acceptable?
There is a difference between analysis and accounting. There are many financial models (e.g. Black-Scholes-Merton option pricing) that are analytic in nature and use transcendental functions, so the idea of getting an exact, arbitrary-precision answer is hopeless. Using a decimal type for this kind of computation would be an exercise in slowing down processing by a few orders of magnitude.
Re: Using floating-point numbers for money
#13From the summary:
"if you are doing some financial math that does not need to be accurate to the penny"...
Of course, if you can accept rounding errors, it is fine. But in many monetary applications, that is not OK. The article is quite pointless.
Edit. For example, when doing budget forecasts, the result will never be accurate to the penny. It is then OK. But when doing accounting, you need to account for every penny. Not OK.
Re: Using floating-point numbers for money
#14The author links to an article about how Excel does all its computations in 64-bit floating point, in a way that seems to bolster their point. The actual title of that article? “Floating-point arithmetic may give inaccurate results in Excel” (https://docs.microsoft.com/en-us/office/troubleshoot/excel/f...).
How coincidental that this should show up on the front page at the same time as the thread on normalization of deviance in software: https://news.ycombinator.com/item?id=22144330
What is wrong with using a currency library?
Re: Using floating-point numbers for money
#15The funny thing is that if you're dealing with (US Treasury) bonds, (EDIT: binary) floats are actually kind-of the right thing, since they trade in 32nds of a dollar (and binary fractions thereof)[1][2]
> Unlike U.S. equity markets, which switched to decimal pricing in 2001, U.S. Treasury securities still trade in fractions. In particular, prices are quoted in 32nds of a point, where a point equals one percent of par, with the 32nds themselves split into fractions. On the BrokerTec platform, for example, 3- and 5-year notes trade in quarters of 32nds, whereas 7-, 10-, and 30-year securities trade in halves of 32nds. The quoted price for a 5-year note might be 98-15¼, for example, indicating a price in decimal form of 98.4765625 (that is, 98 + 15⁄32 + ¼⁄32).
[1] https://www.newyorkfed.org/aboutthefed/fedpoint/fed07.html
[2] https://www.bloomberg.com/opinion/articles/2020-01-15/it-s-n...
Re: Using floating-point numbers for money
#16Aside from rounding I have 2 reasons to not use them where (financial) precision is necessary:
- https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe... (it's the same in other languages)
- if results are not exactly reversible then you cannot implement verification and that hinders defensive programming
Re: Using floating-point numbers for money
#17There’s more to money than what happens in the checkout line, and that’s where the problems with floating-point math arises. For example, one codebase I’m aware of ran into serious problems with line item refunds when currency conversion was involved, IIRC. (“Serious” as in “couldn’t generate a refund that exactly matched the charge on the customer’s original invoice.”)
Exactly, the results are not reversible if you apply rounding.
Re: Using floating-point numbers for money
#18A lot of financial firms use an integer of the smallest indivisible unit of currency wherever possible (stripe is one). This has the handy property that string and numeric representations are identical so no risk of being flipped into scientific notation by some layer. That happens more often than you’d think.
FX is a different world. Spot FX trading systems are fully automated and compute rates to 5 DP. That was 15 years ago, I don’t know if it’s more now. Large Yen amounts can come worryingly close to the limits of precision.
I once watched a colleague trying to persuade a roomful of people to stop using floats. The demo showed what happens to 0.1 + 0.1 + 0.1. The answer was not 0.3. I’m not sure they believed him. Some of them are probably still writing software for your bank!
Re: Using floating-point numbers for money
#19Earlier quoted context omitted.
Good floating-point printing functions output the shortest possible representation. So if 2.675 and 2.6749999999999998 are indistinguishable, print(2.6749999999999998) will show 2.675
My impression was that the article is about intermediate rounding between calculation steps, rather than about printing a number to the screen.
As far as (64-bit binary) floats are concerned, 2.675 and 2.6749999999999998 are in fact the same thing:
$ python3
Python 3.7.3 (default, Jun 16 2019, 16:10:46)
[Clang 8.0.0 (clang-800.0.42.1)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> 2.675 == 2.6749999999999998
True
Of course, correct rounding is still an issue when using a decimal type, since round(sum(n for n in ns)) ≠ sum(round(n) for n in ns).
Re: Using floating-point numbers for money
#20This is not great advice, and he defeats his own argument without realizing it. The main problem with this article is the damn title, which is absolutely awful advice. The body of the article ultimately contradicts the title. Anyone who didn't read the article but read the title might be more likely to use floating point numbers for money now.
> One piece of popular programming wisdom is "never using floating-point numbers for money." This has never made sense to me.
He then goes on to explain why it absolutely does and must make sense. It honestly seems like the author's entire point is about not accepting blanket statements.
> My summary: if you are doing some financial math that does not need to be accurate to the penny, just use floating point numbers.
Arguably all financial math needs to be accurate to the penny. I can't help but think he is maliciously trolling, trying to convince people of something that isn't true.