Mark Dickinson dicki...@gmail.com added the comment:
Fixed in r77062 (trunk), r77063 (py3k).
--
resolution: - fixed
stage: patch review - committed/rejected
status: open - closed
___
Python tracker rep...@bugs.python.org
Mark Dickinson dicki...@gmail.com 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 rep...@bugs.python.org
Mark Dickinson dicki...@gmail.com 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
Mark Dickinson dicki...@gmail.com 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__
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
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.
--
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
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 amateur
Mark Dickinson added the comment:
Tim: is this worth fixing?
--
nosy: +tim_one
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1811
__
___
Python-bugs-list mailing list
Changes by Raymond Hettinger:
--
assignee: - tim_one
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1811
__
___
Python-bugs-list mailing list
Unsubscribe:
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 Python
Changes by Mark Dickinson:
--
components: +Interpreter Core
versions: +Python 2.6, Python 3.0
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1811
__
___
12 matches
Mail list logo
