[issue1811] True division of integers could be more accurate

Mark Dickinson added the comment: Fixed in r77062 (trunk), r77063 (py3k). -- resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed ___ Python tracker ___

[issue1811] True division of integers could be more accurate

Mark Dickinson added the comment: Here's an updated patch, against py3k. On my machine, a/b is a touch faster with this patch when abs(a), abs(b) are smaller than 1e15 or so; it's (inevitably) slower than the existing implementation for larger a and b. For 'random' a and b, average runnin

[issue1811] True division of integers could be more accurate

Mark Dickinson added the comment: Stealing this from Tim, with the intention of acting on it in the next couple of weeks. -- assignee: tim_one -> mark.dickinson ___ Python tracker _

[issue1811] True division of integers could be more accurate

Mark Dickinson added the comment: An example of a case that's almost 3.5 ulps out (Python 2.6): Python 2.6.2 (r262:71600, Jul 8 2009, 09:56:31) [GCC 4.0.1 (Apple Inc. build 5490)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> from __future__ import divis

[issue1811] True division of integers could be more accurate

Mark Dickinson <[EMAIL PROTECTED]> added the comment: Here's a patch that fixes the rounding of integer division. It includes a fast path for the case where both integers are small (less than about 3.5e12). -- keywords: +patch Added file: http://bugs.python.org/file10363/long_division

[issue1811] True division of integers could be more accurate

Terry J. Reedy <[EMAIL PROTECTED]> added the comment: To my mind, the inaccurate result is a bug that should be fixed. Note: (3.0a3) >>> 10e40/10e39 10.0 The rationale for the division change is that (as far as reasonably possible) arithmetic operations with same values should give same result

[issue1811] True division of integers could be more accurate

Mark Dickinson added the comment: A related problem is that float(n) isn't always correctly rounded for an integer n. A contrived example: >>> n = 2**68 + 2**16 - 1 >>> float(n) 2.9514790517935283e+20 Here the difference between float(n) and the true value of n is around 0.8 ulps; a co

[issue1811] True division of integers could be more accurate

Changes by Raymond Hettinger: -- assignee: -> tim_one __ Tracker <[EMAIL PROTECTED]> __ ___ Python-bugs-list mailing list Unsubscribe: http:/

[issue1811] True division of integers could be more accurate

Mark Dickinson added the comment: Tim: is this worth fixing? -- nosy: +tim_one __ Tracker <[EMAIL PROTECTED]> __ ___ Python-bugs-list mailing l

[issue1811] True division of integers could be more accurate

Christian Heimes added the comment: Mark Dickinson wrote: > To get proper timings I'd have to code this up properly. I'll do this, > unless there's > a consensus that it would be a waste of time :) Why don't you ask Tim? He is the right person for the discussion. I'm only an interested amateu

[issue1811] True division of integers could be more accurate

Mark Dickinson added the comment: It would be easy and safe to just use a/b = float(a)/float(b) if both a and b are less than 2**53 (assuming IEEE doubles). Then there wouldn't be any loss of speed for small integers. For large integers the algorithm I posted should run in time linear in th

[issue1811] True division of integers could be more accurate

Christian Heimes added the comment: How fast is your algorithm compared to the current algorithm and where starts the break even zone? Most users use only small integers so it might be a good idea to use a simpler algorithm for longs with Py_SIZE() == 1. This is important for py3k. -- no

[issue1811] True division of integers could be more accurate

Changes by Mark Dickinson: -- components: +Interpreter Core versions: +Python 2.6, Python 3.0 __ Tracker <[EMAIL PROTECTED]> __ ___ Python-bugs-

[issue1811] True division of integers could be more accurate

New submission from Mark Dickinson: Division of two longs can produce results that are needlessly inaccurate: >>> from __future__ import division >>> 10**40/10**39 10.002 The correct result is, of course, 10.0, which is exactly representable as a float. The attached snippet of Py