Martin v. Löwis added the comment:
I talked to a bunch of people (n=7) here at the company where I also
give Python courses from time to time. I asked them two questions:
1. Is this behavior of FD what you would expect?
2. Given the current behavior of FD, what use cases do you see?
The
Martin v. Löwis added the comment:
Zitat von Tom Pohl rep...@bugs.python.org:
This is not: 1 // 0.1 = 9.0 because math.floor(1/0.1) is able to
come up with the result that is expected from an operator called
floor division.
You apparently assume that it is possible to give a definition
Mark Dickinson added the comment:
I believe that definining x//y as math.floor(x/y) is also confusing
in other cases (without being able to construct such cases right away).
In addition, defining x//y as math.floor(x / y) would break its connection with
%: a key invariant is that
(x //
Tom Pohl added the comment:
Mark, thanks for explaining the connection of // and %. Finally, I can see why
somebody would want to stick to the current behavior of FD.
It renders FD useless for all of my use cases, but there are simple
alternatives.
Thanks for your time,
Tom
--
Martin v. Löwis added the comment:
Am 12.11.12 14:53, schrieb Tom Pohl:
What do I expect from FD (x//y):
1. Perform a division (I don't care about the details here).
2. Return an integer value q (even if it's stored in a float).
3. The absolute difference between the mathematical division
Tom Pohl added the comment:
You still get me wrong. Thanks to your explanations and to my personal
knowledge about this topic (programming for 28 years now; PhD in
CS/numerics/HPC) I now fully understand the technical details about the current
implementation of FD. The problem I see is that
Raymond Hettinger added the comment:
FWIW, I agree with this being closed. The current behavior is a fact-of-life
for anyone using binary floating point.
The decimal module is provided people who want more intuitive behaviors when
dividing by numbers like 0.1 which are exactly
Tom Pohl added the comment:
This is a fact-of-life for anyone using binary floating point:
x = 0.0
while x != 1.0: print(x); x += 0.1 # so long
This is not: 1 // 0.1 = 9.0 because math.floor(1/0.1) is able to come up with
the result that is expected from an operator called floor division.
New submission from Tom Pohl:
According to the documentation of the floor division
(http://docs.python.org/2/reference/expressions.html#binary-arithmetic-operations),
x//y should be equal to math.floor(x/y).
However, the result of 1//0.1 is 9.0 (tested on 2.6, 2.7, 3.2).
It might be related
Changes by Ezio Melotti ezio.melo...@gmail.com:
--
nosy: +mark.dickinson, skrah
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16460
___
___
Serhiy Storchaka added the comment:
Yes, this is related to the internal representation of floating-point numbers.
0.1 is 3602879701896397/36028797018963968 in float.
import fractions
fractions.Fraction(0.1)
Fraction(3602879701896397, 36028797018963968)
36028797018963968 / 3602879701896397
Mark Dickinson added the comment:
9.0 *is* the correct result here. The number that Python stores for 0.1 is an
approximation that's actually a little greater than 0.1.
--
resolution: - invalid
___
Python tracker rep...@bugs.python.org
Changes by Mark Dickinson dicki...@gmail.com:
--
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16460
___
___
Tom Pohl added the comment:
Thanks for your comments. From a technical/numerical point of view I agree with
you that the computed result is correct given the floating-point limitations.
From a user's point of view (and the documentation seems to agree with me) the
result is wrong. The
Mark Dickinson added the comment:
Tom: there's no reasonable way to define all 3 of /, // and % for
floating-point numbers that avoids all user surprises. There are a couple of
notes (nos 2 and 3) at the bottom of the documentation page you refer to that
attempt to explain some of the
Martin v. Löwis added the comment:
Tom: you are misinterpreting the docs. It says (paraphrased) that the result of
x//y equals floor(x mathematically-divided-by y), which is different from
floor(x/y). Your computer is not capable of performing the
mathematically-divided-by operation; you have
Serhiy Storchaka added the comment:
Your computer is not capable of performing the mathematically-divided-by
operation; you have to compute it on paper.
You can compute it with Python.
math.floor(1/fractions.Fraction(0.1))
9
--
___
Python
Tom Pohl added the comment:
Thanks for all the explanations why Python's floor division (FD) works as
specified. And I agree, it does work as specified, but still, I think this is
not the behavior that most people would expect and is therefore dangerous to
provide/use.
What do I expect from
Tom Pohl added the comment:
Martin:
Ok, just as you suggested, I did the calculations on a sheet of paper:
floor(1 mathematically-divided-by 0.1) = floor(10) = 10
qed ;-)
--
___
Python tracker rep...@bugs.python.org
Stefan Krah added the comment:
Any programming language that uses binary floats behaves like that
and it is actually what people expect.
If you want behavior that is closer to pencil and paper calculations,
you need to use decimal:
Decimal(1) // Decimal(0.1)
Decimal('10')
Contrast with:
Tom Pohl added the comment:
Since nobody seems to share my point of view, I give up. :-)
Thanks for your support and for working on Python (the best programming
language as we all know),
Tom
--
___
Python tracker rep...@bugs.python.org
21 matches
Mail list logo
