Python math is off by .000000000000045

Simple mathematical problem, + and - only:

>>> 1800.00-1041.00-555.74+530.74-794.95
-60.950000000000045

That's wrong.

Proof
http://www.wolframalpha.com/input/?i...B530.74-794.95
-60.95 aka (-(1219/20))

Is there a reason Python math is only approximated? - Or is this a bug?

Thanks for all info,

Alec Taylor

On Feb 22, 1:13*pm, Alec Taylor <alec.tayl...@gmail.com> wrote:
> Simple mathematical problem, + and - only:
>
> >>> 1800.00-1041.00-555.74+530.74-794.95
>
> -60.950000000000045
>
> That's wrong.
>
> Proofhttp://www.wolframalpha.com/input/?i=1800.00-1041.00-555.74%2B530.74-...
> -60.95 aka (-(1219/20))
>
> Is there a reason Python math is only approximated? - Or is this a bug?
>
> Thanks for all info,
>
> Alec Taylor

I get the right answer if I use the right datatype:

>>> import decimal

>>> D=decimal.Decimal

>>> D('1800.00')-D('1041.00')-D('555.74')+D('530.74')-D('794.95')

Decimal('-60.95')

Alec Taylor writes:

> Simple mathematical problem, + and - only:
>
> >>> 1800.00-1041.00-555.74+530.74-794.95
> -60.950000000000045
>
> That's wrong.

Not by much. I'm not an expert, but my guess is that the exact value
is not representable in binary floating point, which most programming
languages use for this. Ah, indeed:

>>> 0.95
0.94999999999999996

Some languages hide the error by printing fewer decimals than they use
internally.

> Proof
> http://www.wolframalpha.com/input/?i...B530.74-794.95
> -60.95 aka (-(1219/20))
>
> Is there a reason Python math is only approximated? - Or is this a bug?

There are practical reasons. Do learn about "floating point".

There is a price to pay, but you can have exact rational arithmetic in
Python when you need or want it - I folded the long lines by hand
afterwards:

>>> from fractions import Fraction
>>> 1800 - 1041 - Fraction(55574, 100) + Fraction(53074, 100)
- Fraction(79495, 100)
Fraction(-1219, 20)
>>> -1219/20
-61
>>> -1219./20
-60.950000000000003
>>> float(1800 - 1041 - Fraction(55574, 100) + Fraction(53074, 100)
- Fraction(79495, 100))
-60.950000000000003

On 2012-02-22, Alec Taylor <alec.taylor6@gmail.com> wrote:

> Simple mathematical problem, + and - only:
>
>>>> 1800.00-1041.00-555.74+530.74-794.95
> -60.950000000000045
>
> That's wrong.

Oh good. We haven't have this thread for several days.

> Proof
> http://www.wolframalpha.com/input/?i...B530.74-794.95
> -60.95 aka (-(1219/20))
>
> Is there a reason Python math is only approximated?

http://docs.python.org/tutorial/floatingpoint.html

Python uses binary floating point with a fixed size (64 bit IEEE-754
on all the platforms I've ever run across). Floating point numbers
are only approximations of real numbers. For every floating point
number there is a corresponding real number, but 0% of real numbers
can be represented exactly by floating point numbers.

> - Or is this a bug?

No, it's how floating point works.

If you want something else, then perhaps you should use rationals or
decimals:

http://docs.python.org/library/fractions.html
http://docs.python.org/library/decimal.html

--
Grant Edwards grant.b.edwards Yow! What I want to find
at out is -- do parrots know
gmail.com much about Astro-Turf?

> For every floating point
> number there is a corresponding real number, but 0% of real numbers
> can be represented exactly by floating point numbers.

It seems to me that there are a great many real numbers that can be
represented exactly by floating point numbers. The number 1 is an
example.

I suppose that if you divide that count by the infinite count of all
real numbers, you could argue that the result is 0%.

On Sat, 2012-02-25 at 09:56 -0800, Tobiah wrote:
> > For every floating point
> > number there is a corresponding real number, but 0% of real numbers
> > can be represented exactly by floating point numbers.
>
> It seems to me that there are a great many real numbers that can be
> represented exactly by floating point numbers. The number 1 is an
> example.
>
> I suppose that if you divide that count by the infinite count of all
> real numbers, you could argue that the result is 0%.

It's not just an argument - it's mathematically correct.

The same can be said for ints representing the natural numbers, or
positive integers.

However, ints can represent 100% of integers within a specific range,
where floats can't represent all real numbers for any range (except for
the empty set) - because there's an infinate number of real numbers
within any non-trivial range.


Tim

On 2/25/2012 12:56 PM, Tobiah wrote:

> It seems to me that there are a great many real numbers that can be
> represented exactly by floating point numbers. The number 1 is an
> example.

Binary floats can represent and integer and any fraction with a
denominator of 2**n within certain ranges. For decimal floats,
substitute 10**n or more exactly, 2**j * 5**k since if J < k,
n / (2**j * 5**k) = (n * 2**(k-j)) / 10**k and similarly if j > k.

--
Terry Jan Reedy

>>> (2.0).hex()
'0x1.0000000000000p+1'
>>> (4.0).hex()
'0x1.0000000000000p+2'
>>> (1.5).hex()
'0x1.8000000000000p+0'
>>> (1.1).hex()
'0x1.199999999999ap+0'
>>>

jmf

On Sat, 25 Feb 2012 13:25:37 -0800, jmfauth wrote:

>>>> (2.0).hex()
> '0x1.0000000000000p+1'
>>>> (4.0).hex()
> '0x1.0000000000000p+2'
>>>> (1.5).hex()
> '0x1.8000000000000p+0'
>>>> (1.1).hex()
> '0x1.199999999999ap+0'
>>>>
>>>>
> jmf

What's your point? I'm afraid my crystal ball is out of order and I have
no idea whether you have a question or are just demonstrating your
mastery of copy and paste from the Python interactive interpreter.



--
Steven

On Sat, Feb 25, 2012 at 2:08 PM, Tim Wintle <tim.wintle@teamrubber.com> wrote:
> > It seems to me that there Â*are a great many real numbers that can be
> > represented exactly by floating point numbers. Â*The number 1 is an
> > example.
> >
> > I suppose that if you divide that count by the infinite count of all
> > real numbers, you could argue that the result is 0%.
>
> It's not just an argument - it's mathematically correct.

^ this

The floating point numbers are a finite set. Any infinite set, even
the rationals, is too big to have "many" floats relative to the whole,
as in the percentage sense.

----

In fact, any number we can reasonably deal with must have some finite
representation, even if the decimal expansion has an infinite number
of digits. We can work with pi, for example, because there are
algorithms that can enumerate all the digits up to some precision. But
we can't really work with a number for which no algorithm can
enumerate the digits, and for which there are infinitely many digits.
Most (in some sense involving infinities, which is to say, one that is
not really intuitive) of the real numbers cannot in any way or form be
represented in a finite amount of space, so most of them can't be
worked on by computers. They only exist in any sense because it's
convenient to pretend they exist for mathematical purposes, not for
computational purposes.

What this boils down to is to say that, basically by definition, the
set of numbers representable in some finite number of binary digits is
countable (just count up in binary value). But the whole of the real
numbers are uncountable. The hard part is then accepting that some
countable thing is 0% of an uncountable superset. I don't really know
of any "proof" of that latter thing, it's something I've accepted
axiomatically and then worked out backwards from there. But surely
it's obvious, somehow, that the set of finite strings is tiny compared
to the set of infinite strings? If we look at binary strings,
representing numbers, the reals could be encoded as the union of the
two, and by far most of them would be infinite.


Anyway, all that aside, the real numbers are kind of dumb.

-- Devin

On 2/25/2012 9:49 PM, Devin Jeanpierre wrote:


> What this boils down to is to say that, basically by definition, the
> set of numbers representable in some finite number of binary digits is
> countable (just count up in binary value). But the whole of the real
> numbers are uncountable. The hard part is then accepting that some
> countable thing is 0% of an uncountable superset. I don't really know
> of any "proof" of that latter thing, it's something I've accepted
> axiomatically and then worked out backwards from there.

Informally, if the infinity of counts were some non-zero fraction f of
the reals, then there would, in some sense, be 1/f times a many reals as
counts, so the count could be expanded to count 1/f reals for each real
counted before, and the reals would be countable. But Cantor showed that
the reals are not countable.

But as you said, this is all irrelevant for computing. Since the number
of finite strings is practically finite, so is the number of algorithms.
And even a countable number of algorithms would be a fraction 0, for
instance, of the uncountable predicate functions on 0, 1, 2, ... . So we
do what we actually can that is of interest.

--
Terry Jan Reedy

On 25 fév, 23:51, Steven D'Aprano <steve
+comp.lang.pyt...@pearwood.info> wrote:
> On Sat, 25 Feb 2012 13:25:37 -0800, jmfauth wrote:
> >>>> (2.0).hex()
> > '0x1.0000000000000p+1'
> >>>> (4.0).hex()
> > '0x1.0000000000000p+2'
> >>>> (1.5).hex()
> > '0x1.8000000000000p+0'
> >>>> (1.1).hex()
> > '0x1.199999999999ap+0'
>
> > jmf
>
> What's your point? I'm afraid my crystal ball is out of order and I have
> no idea whether you have a question or are just demonstrating your
> mastery of copy and paste from the Python interactive interpreter.
>


It should be enough to indicate the right direction
for casual interested readers.

Curiosity prompts me to ask...

Those of you who program in other languages regularly: if you visit
comp.lang.java, for example, do people ask this question about
floating-point arithmetic in that forum? Or in comp.lang.perl?

Is there something about Python that exposes the uncomfortable truth
about practical computer arithmetic that these other languages
obscure? For of course, arithmetic is surely no less accurate in
Python than in any other computing language.

I always found it helpful to ask someone who is confused by this issue
to imagine what the binary representation of the number 1/3 would be.

0.011 to three binary digits of precision:
0.0101 to four:
0.01011 to five:
0.010101 to six:
0.0101011 to seven:
0.01010101 to eight:

And so on, forever. So, what if you want to do some calculator-style
math with the number 1/3, that will not require an INFINITE amount of
time? You have to round. Rounding introduces errors. The more
binary digits you use for your numbers, the smaller those errors will
be. But those errors can NEVER reach zero in finite computational
time.

If ALL the numbers you are using in your computations are rational
numbers, you can use Python's rational and/or decimal modules to get
error-free results. Learning to use them is a bit of a specialty.

But for those of us who end up with numbers like e, pi, or the square
root of 2 in our calculations, the compromise of rounding must be
accepted.

On 2/26/2012 7:24 PM, John Ladasky wrote:

> I always found it helpful to ask someone who is confused by this issue
> to imagine what the binary representation of the number 1/3 would be.
>
> 0.011 to three binary digits of precision:
> 0.0101 to four:
> 0.01011 to five:
> 0.010101 to six:
> 0.0101011 to seven:
> 0.01010101 to eight:
>
> And so on, forever. So, what if you want to do some calculator-style
> math with the number 1/3, that will not require an INFINITE amount of
> time? You have to round. Rounding introduces errors. The more
> binary digits you use for your numbers, the smaller those errors will
> be. But those errors can NEVER reach zero in finite computational
> time.

Ditto for 1/3 in decimal.
....
0.33333333 to eitht

> If ALL the numbers you are using in your computations are rational
> numbers, you can use Python's rational and/or decimal modules to get
> error-free results.

Decimal floats are about as error prone as binary floats. One can only
exact represent a subset of rationals of the form n / (2**j * 5**k). For
a fixed number of bits of storage, they are 'lumpier'. For any fixed
precision, the arithmetic issues are the same.

The decimal module decimals have three advantages (sometimes) over floats.

1. Variable precision - but there are multiple-precision floats also
available outside the stdlib.

2. They better imitate calculators - but that is irrelevant or a minus
for scientific calculation.

3. They better follow accounting rules for financial calculation,
including a multiplicity of rounding rules. Some of these are laws that
*must* be followed to avoid nasty consequences. This is the main reason
for being in the stdlib.

> Learning to use them is a bit of a specialty.

Definitely true.

--
Terry Jan Reedy

On Sun, 26 Feb 2012 16:24:14 -0800, John Ladasky wrote:

> Curiosity prompts me to ask...
>
> Those of you who program in other languages regularly: if you visit
> comp.lang.java, for example, do people ask this question about
> floating-point arithmetic in that forum? Or in comp.lang.perl?

Yes.

http://stackoverflow.com/questions/5...ts-math-broken

And look at the "Linked" sidebar. Obviously StackOverflow users no more
search the internet for the solutions to their problems than do
comp.lang.python posters.


http://compgroups.net/comp.lang.java...roundoff-error



--
Steven