31–40 of 120 posts
Earlier quoted context omitted.
To be precise, it’s C’s `expm1`. Like other things in math.h, it’s just adopted as is to most popular languages, even including PHP and JS.
expm1 is specified in IEEE 754-2008 (didn't bother to check old revisions)
Earlier quoted context omitted.
Assuming you want your money to actually add up correctly, then floats are always the wrong choice. If you’re not interested in accurate accounting, the. Sure floats are fine, but when you’re working with money, accurate accounting tends to be the expectation.
Addition is one of those things that does work pretty predictably and error free with floats. The problem with 0.30000000000000004 etc is usually that the things you are adding are not what you expect (float(0.1) != 0.1), i.e. the difficulty usually is string float conversions rather than float arithmetic itself.
Earlier quoted context omitted.
Assuming you want your money to actually add up correctly, then floats are always the wrong choice. If you’re not interested in accurate accounting, the. Sure floats are fine, but when you’re working with money, accurate accounting tends to be the expectation.
If you're the one settling the books at your bank, sure. If you just need to display the price of something, a float+money formatter is mostly fine.
I decided years ago that the next time I hear someone suggesting we use floats / doubles to represent money amounts, I am going to punch them in the face.
This gets repeated a lot, and I don't disagree. But I find odd that doubles would be so unsuitable for monetary (and other similar) arithmetic; in principle you have 15 significant digits which should be more than enough, and precise control how the results are rounded. And all the basic arithmetic should return correctly rounded values to the last ULP. So it is weird that those tools are still not good enough and it…
X87 does not really factor into it, if anything in your view of the world x87 floats would be better since x86-EP is 80 bits. Except its involvement now leads to intermediate-precision-driven inconsistencies.
Control (which you mention) and consistency are the issues, as well as the interaction between that and comparators.
Guarding against floating-point issues or considering precision errors is neither part of school-learned arithmetics, nor of most CS programs, to almost every developer just flings around floats like they’re genuine reals, and when problems start surfacing floats are so threaded through without consideration it becomes very hard to untangle, which leads to local patch jobs which make the problem worse.
Earlier quoted context omitted.
For a summation, add the smaller numbers first. Smaller as in 0.0000000000053, not like -5172365126.
For summation just go with Kahan summation or some improved variant of it https://en.wikipedia.org/wiki/Kahan_summation_algorithm
Earlier quoted context omitted.
I see! yes, the magic is you can cancel the noise by repeating it twice: ``` In [1]: math.exp(1e-15)-1 Out[1]: 1.1102230246251565e-15 In [2]: math.log(math.exp(1e-15)) Out[2]: 1.110223024625156e-15 ``` risky business though, I imagine it's implementation dependent
It’s not (or shouldn’t be), it’s simply a result of math, as the article explains in length.
I decided years ago that the next time I hear someone suggesting we use floats / doubles to represent money amounts, I am going to punch them in the face.
The rule as stated is way too strong, for example option prices are money amounts but floats are unavoidable in calculating them. For a less exotic example, consider that Excel, widely used by actual accountants, uses floats throughout to represent numbers.
If you’d ever had to bill millions of customers for precise amounts of electricity and gas at precise prices… you would hate floats and you’d hate that any idiot will act as though excel is gospel truth.
Earlier quoted context omitted.
If you're the one settling the books at your bank, sure. If you just need to display the price of something, a float+money formatter is mostly fine.
Mostly. You might be surprised how much of a headache it creates when things are off by a little in ways customers don't understand even when you're not settling transactions like that. Customers get confused when they get receipts or invoices where things don't add up, even when it saves them a penny! I've seen rounding down make people mad because it didn't add up when discounts were applied even when they were the…
Then what's the best way to handle these cases? Are there any set of rules we should use while implementing the mathematical equations dealing with limits in floating points.
Earlier quoted context omitted.
This gets repeated a lot, and I don't disagree. But I find odd that doubles would be so unsuitable for monetary (and other similar) arithmetic; in principle you have 15 significant digits which should be more than enough, and precise control how the results are rounded. And all the basic arithmetic should return correctly rounded values to the last ULP. So it is weird that those tools are still not good enough and it…
The problems of floats are not the number of significant digits, it’s the imprecision of the representation (floats don’t just cut off at the end), that these imprecisions compound, and that float operations are not commutative. At the end of the day, 0.1 + 0.2 != 0.3 is a fact you have to live with. X87 does not really factor into it, if anything in your view of the world x87 floats would be better since x86-EP is 8…
That is the one example that floats around a lot, but its also imho not very good one. '0.1', '0.2', and '0.3' are not floating point values, so the premise is flawed.
0.1000000000000000055511151231257827021181583404541015625
+ 0.200000000000000011102230246251565404236316680908203125
!= 0.299999999999999988897769753748434595763683319091796875
Also `round(0.1 + 0.2, 15) == 0.3` is true (in python), so being conscious about rounding things appropriately goes long way. And I imagine that correct rounding is relevant in monetary calculations no matter what sort of numbers you are using, so while while floats the situation might be more pronounced I don't see it being such fundamental problem.