[issue18739] math.log of a long returns a different value of math.log of an int
Mark Dickinson added the comment: Patch applied. -- resolution: - fixed status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18739 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18739] math.log of a long returns a different value of math.log of an int
Roundup Robot added the comment: New changeset f543863f4e43 by Mark Dickinson in branch '2.7': Issue #18739: Fix inconsistent results from math.log(n) and math.log(long(n)) http://hg.python.org/cpython/rev/f543863f4e43 -- nosy: +python-dev ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18739 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18739] math.log of a long returns a different value of math.log of an int
Mark Dickinson added the comment: Ah, Tim saw through my cunningly-laid false trail of incorrect issue numbers. Step 1 of my world domination plan is foiled! Yes, let's fix this. In my mind, it's definitely a bug that ints and longs aren't interchangeable here, and it would be nice to have 2.7 and 3.x behaving the same way. I do have some worries about the fix breaking / changing existing code, but given that it'll only affect log of a long, those worries barely register. -- type: - behavior ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18739 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18739] math.log of a long returns a different value of math.log of an int
Tim Peters added the comment: +1 on fixing it in 2.7, for the reasons Mark gave. Way back when I introduced the original scheme, log(a_long) raised an exception, and the `int` and `long` types had a much higher wall between them. The original scheme changed an annoying failure into a pretty good approximation, and because int operations never returned a long back then the relatively rare code using longs forced their use. In the meantime, you can change failing cases of log(some_long) to log(int(some_long)). int(some_long) will convert to int if possible (avoiding this path in the log code), but return some_long unchanged otherwise. In the old days, int(some_long) would fail if some_long was too big to fit in an int - that's different now too - and for the better :-) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18739 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18739] math.log of a long returns a different value of math.log of an int
Mark Dickinson added the comment: Here's a patch that simply backports the Python 3.x code to Python 2.7. -- keywords: +patch Added file: http://bugs.python.org/file31304/issue18739.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18739 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18739] math.log of a long returns a different value of math.log of an int
Changes by Mark Dickinson dicki...@gmail.com: -- assignee: - mark.dickinson ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18739 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18739] math.log of a long returns a different value of math.log of an int
New submission from Gregory P. Smith: This is a very odd inconsistency in math.log behavior. That said, it is probably only a single bit imprecision at the end of the float result. Still, 10 == 10L so I'd expect math.log of both to give the same result. oss/cpython/2.7:LOAS$ ./python Python 2.7.5+ (2.7:395ac61ebe1a, Aug 14 2013, 07:11:35) [GCC 4.6.3] on linux2 Type help, copyright, credits or license for more information. import math math.log(10) - math.log(10L) 4.440892098500626e-16 math.log(10) 2.302585092994046 math.log(10L) 2.3025850929940455 In Python 3.3 things seem fine and match the int behavior from 2.7 above despite the internal number implementation being a PyLong in 3.x: math.log(10) 2.302585092994046 -- messages: 195175 nosy: gregory.p.smith priority: normal severity: normal status: open title: math.log of a long returns a different value of math.log of an int versions: Python 2.7 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18739 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18739] math.log of a long returns a different value of math.log of an int
Christian Heimes added the comment: Fascinating, how did you find the issue? -- nosy: +christian.heimes, mark.dickinson ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18739 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18739] math.log of a long returns a different value of math.log of an int
Tim Peters added the comment: Yup - 2.7 evaluates this in a less precise way, as log(10L) = log(10./16 * 2**4) = log(0.625) + log(2)*4 log(10L) == log(0.625) + log(2)*4 True This patterns works well even for longs that are far too large to represent as a double; e.g., log(1L 5) 34657.35902799726 which is evaluated internally as log(0.5) + log(2) * 50001: log(1L 5) == log(0.5) + log(2) * 50001 True Python 3 is more careful, falling back to this pattern _only_ if converting the long to a double overflows. Of course 10L can be represented exactly as a double, so Python 3 evaluates it directly as log(float(10L)) = log(10.0). It's minor difference overall, but definitely visible ;-) -- nosy: +tim_one ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18739 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18739] math.log of a long returns a different value of math.log of an int
Gregory P. Smith added the comment: We found this while refactoring an API to be more consistent about returning longs vs ints in specific cases. This resulted in another unittest that was using math.log for a nicer display of the value by magnitude to fail as the result was slightly different for the two input types. arguably that is a fragile test as it cares about the last couple bits of a float... but that such a test exists does suggest that making a future 2.7.6+ release more pedantic about the behavior on values that safely fit into a double might break an odd test or three out there. OTOH, it makes things more consistent all around and match 3.x in both cases so I'm still be for doing it. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18739 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18739] math.log of a long returns a different value of math.log of an int
Tim Peters added the comment: FYI, the improvement was made in these 2 changesets: c8dc4b5e54fb a9349fd3d0f7 If desired, those could presumably be grafted back into the 2.7 branch. The commit messages refer to issue #9599, but that appears to be mistaken. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18739 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18739] math.log of a long returns a different value of math.log of an int
Tim Peters added the comment: OK, the correct one is issue #9959. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18739 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
