Python -- floating point arithmetic

Adam Skutt askutt at gmail.com
Thu Jul 8 06:58:27 EDT 2010


On Jul 8, 12:53 am, "Zooko O'Whielacronx" <zo... at zooko.com> wrote:
> I don't understand. I described two different problems: problem one is
> that the inputs, outputs and literals of your program might be in a
> different encoding (in my experience they have most commonly been in
> decimal). Problem two is that your computations may be lossy. If the
> inputs, outputs and literals of your program are decimal (as they have
> been for most of my programs) then using decimal is better than using
> float because of problem one. Neither has a strict advantage over the
> other in terms of problem two.

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.  It should be instructive and telling that mplayer now
strongly prefers the rational expressions over the decimal ones.  Just
because you haven't rounded your input in parsing it doesn't change
the fact your input may have be rounded before it was presented to the
program, which is the reality of the matter more often than not.

Even in fields where the numbers are decimal, like finance, the rules
are considerably more complicated than what you were taught in the
"schoolbook".  This is one of the reasons IBM can still make a killing
selling mainframes, they got all of those rules right decades ago.

> > And that will be never true once you
> > start using non trivial computation (i.e. transcendental functions
> > like log, exp, etc...).
>
> I'm sorry, what will never be true? Are you saying that decimals have
> a disadvantage compared to floats? If so, what is their disadvantage?

He's saying that once you get past elementary operations, you quickly
run into irrational numbers, which you will not be representing
accurately.  Moreover, in general, it's impossible to even round
operations involving transcendental functions to an arbitrary fixed-
precision, you may need effectively infinite precision in order to the
computation.  In practice, this means the error induced by a lossy
input conversion (assuming you hadn't already lost information) is
entirely negligible compared to inherent inability to do the necessary
calculations.



More information about the Python-list mailing list