Python -- floating point arithmetic
in [Python]
|
From: Adam Skutt on 8 Jul 2010 13:22 On Jul 8, 12:38 pm, "Zooko O'Whielacronx" <zo...(a)zooko.com> wrote: > On Thu, Jul 8, 2010 at 4:58 AM, Adam Skutt <ask...(a)gmail.com> wrote: > > > I can't think of any program I've ever written where the inputs are > > actually intended to be decimal. Consider a simple video editing > > program, and the user specifies a frame rate 23.976 fps. Is that what > > they really wanted? No, they wanted 24000/1001 but didn't feel like > > typing that. > > Okay, so there was a lossy conversion from the user's intention > (24000/1001) to what they typed in (23.976). > > >>> instr = '23.976' > > Now as a programmer you have two choices: > > 1. accept what they typed in and losslessly store it in a decimal: > > >>> from decimal import Decimal as D > >>> x = D(instr) > >>> print x > > 23.976 > > 2. accept what they typed in and lossily convert it to a float: > > >>> x = float(instr) > >>> print "%.60f" % (x,) > > 23.975999999999999090505298227071762084960937500000000000000000 > > option 2 introduces further "error" between what you have stored in > your program and what the user originally wanted and offers no > advantages except for speed, right? No, you have a third choice, and it's the only right choice: 3. Convert the input to user's desired behavior and behave accordingly. Anything else, here, will result in A/V sync issues. Which is really my point, just because we write '23.976' on the command-line doesn't necessarily mean that's what we meant. Humans are pretty lazy, and we write rational numbers as incomplete decimals all of the time. > But this is not a disadvantage of decimal compared to float is it? > These problems affect both representations. Although perhaps they > affect them differently, I'm not sure. > > I think sometimes people conflate the fact that decimals can easily > have higher and more variable precision than floats with the fact that > decimals are capable of losslessly storing decimal values but floats > aren't. > No, it's not a specific disadvantage of decimal compared to float. I'm not sure why David C. choose to phrase it in those specific terms, though I'm not sure it matters all that much. What I believe is one must understand that the underlying issues are fundamental, and the only way to solve the issues is to educate programmers so they can write code that behaves correctly in the face of rounding. And I do believe you're correct that programmers frequently see one desirable behavior of decimal FP over binary FP and therefore assume all the badness must have gone away. Adam
From: Stefan Krah on 8 Jul 2010 14:00 Adam Skutt <askutt(a)gmail.com> wrote: > > > I actually agree with much of what you've said. �It was just the > > "impossible" claim that went over the top (IMO). �The MPFR library > > amply demonstrates that computing many transcendental functions to > > arbitrary precision, with correctly rounded results, is indeed > > possible. > That's because you're latching onto that word instead of the whole > sentence in context and making a much bigger deal out of than is > appropriate. The fact that I may not be able to complete a given > calculation for an arbitrary precision is not something that can be > ignored. It's the same notional problem with arbitrary-precision > integers: is it better to run out of memory or overflow the > calculation? The answer, of course, is a trick question. In the paper describing his strategy for correct rounding Ziv gives an estimate for abnormal cases, which is very low. This whole argument is a misunderstanding. Mark and I argue that correct rounding is quite feasible in practice, you argue that you want guaranteed execution times and memory usage. This is clear now, but was not so apparent in the "impossible" paragraph that Mark responded to. I think asking for strictly bounded resource usage is reasonable. In cdecimal there is a switch to turn off correct rounding for exp() and log(). Stefan Krah
From: Stefan Krah on 8 Jul 2010 14:11 Mark Dickinson <dickinsm(a)gmail.com> wrote: > On Jul 8, 2:59�pm, Stefan Krah <stefan-use...(a)bytereef.org> wrote: > > pow() is trickier. Exact results have to be weeded out before > > attempting the correction loop for correct rounding, and this is > > complicated. > > > > For example, in decimal this expression takes a long time (in cdecimal > > the power function is not correctly rounded): > > > > Decimal('100.0') ** Decimal('-557.71e-742888888') > > Hmm. So it does. Luckily, this particular problem is easy to deal > with. Though I dare say that you have more up your sleeve. :)? Not at the moment, but I'll keep trying. :) Stefan Krah
From: Zooko O'Whielacronx on 8 Jul 2010 15:15 On Thu, Jul 8, 2010 at 11:22 AM, Adam Skutt <askutt(a)gmail.com> wrote: > On Jul 8, 12:38 pm, "Zooko O'Whielacronx" <zo...(a)zooko.com> wrote: >> Now as a programmer you have two choices: ⦠>> 1. accept what they typed in and losslessly store it in a decimal: ⦠>> 2. accept what they typed in and lossily convert it to a float: > No, you have a third choice, and it's the only right choice: > 3. Convert the input to user's desired behavior and behave > accordingly.  Anything else, here, will result in A/V sync issues. Okay, please tell me about how this is done. I've never dealt with this sort of issue directly. As far as I can imagine, any way to implement option 3 will involve accepting the user's input and storing it in memory somehow and then computing on it. As far as I can tell, doing so with a decimal instead of a float will never be worse for your outcome and will often be better. But, please explain in more detail how this works. Thanks! Regards, Zooko
From: Adam Skutt on 8 Jul 2010 15:33
On Jul 8, 2:00 pm, Stefan Krah <stefan-use...(a)bytereef.org> wrote: > > This whole argument is a misunderstanding. Mark and I argue that correct > rounding is quite feasible in practice, you argue that you want guaranteed > execution times and memory usage. This is clear now, but was not so apparent > in the "impossible" paragraph that Mark responded to. No, that's what I'm arguing for, though such a feature is important. I'm pointing out that the feasibility of correct rounding is entirely dependent on what you're doing. For IEEE-754 double, it's feasible for the elementary functions if you can tolerate intermediate calculations that are more than twice as large as your double in the corner cases. Certainly, for a single calculation, this is acceptable, but at how many calculations is it no longer acceptable? Adam |