This math scares me

[Werner Schiendl]

I do not see an advantage of using decimal floating point arithmetic.
As you mentioned, it slows things down for no obvius gain.

The most useful approach is to round the numbers to 15 digits for display,
because this is the precision double values can really correctly represent.
The drawback is, that the rounded value does not discover all the
information actually stored in the variable.

Tim Peters post explains, why 17 digit representation is used in Python: To
be able to get the representation and evaluate it back to the internal
information without loss of information.

regards
werner

Ken Seehof <kens at sightreader.com> wrote in message
news:mailman.984480856.18097.python-list at python.org...
> You're not alone, but there is a good explanation for what you see, and it
> is not generally considered a bug in python, though some would like to
> change python to give more visually correct results.
>
> This is also true of many other programming languages, such as C and C++.
> The reason is that the computer stores your number in binary.  Turns out
> that 10.55 (or 0.55) does not have an exact representation in binary,
> therefore you get a "rounding error".  To give you an idea of what I am
> talking about, consider that in decimal, you can't represent 1/3 exactly
> (you get 0.33333333...).
>
> Let's take a simpler example:
>
> >>> 0.2
> 0.20000000000000001
>
> What happened here?  Well 0.2 = 1/5, which works fine in decimal.  When
you
> convert that to binary, it looks like this:
> 0.2 (decimal)  =
0.0011001100110011001100110011001100110011001100110011...
> (binary).
>
> The reason your desk calculator gets the right result is that it
represents
> numbers in decimal internally.  If python did the same, it would run
> significantly slower than it does because most computers prefer to do math
> in binary.  However, switching to decimal floating point is a proposed
> change for a future version of python, along with making 1/2 = 0.5 (or
some
> other equivalent answer (right now, 1 / 2 = 0 (try it) ) ) and other
stuff.
>
> Keep in mind that any floating point system will have rounding errors.
> Doing math in decimal merely hides the wierd unexpected ones like the one
> you found (at the cost of slowing things down).  Some people propose that
> python keeps fractional numbers in rational form (i.e. A/B).  This would
> completely solve the rounding error problem (for division and
> multiplication, that is), but would make python really really really slow.
> There are various other compromises but there is unfortunately no good
> solution to this dilemma at all.
>
> These numerical issues cause endless debates among python people.  As you
> will see, there will probably be a stream of endless innane babble in
> response to this message.  I think there's a SIG or a PEP or something
> (couldn't find it) where this debate is supposed to be instead of here.
>
> ----- Original Message -----
> From: "William Park" <parkw at better.net>
> To: <costas at springmail.com>
> Cc: <python-list at python.org>
> Sent: Monday, March 12, 2001 2:03 PM
> Subject: Re: This math scares me
>
>
> > On Mon, Mar 12, 2001 at 09:34:58PM +0000, costas at springmail.com wrote:
> > > Ok, I can see maybe division having problems. But why does addition of
> > > the two numbers below:
> > >
> > > 5.01+5.54
> > >
> > > give me this?
> > >
> > > 10.550000000000001
> >
> > It's called 'Round-off error'.
> >
> > ---William Park, Open Geometry Consulting, Linux/Python, 8 CPUs.
> >
> > --
> > http://mail.python.org/mailman/listinfo/python-list
> >
>
>