classification
Title: 3.0/3.1: Bad bug in range() computation (or possible Integer problem)
Type: behavior Stage: resolved
Components: Interpreter Core Versions: Python 3.0
process
Status: closed Resolution: fixed
Dependencies: Superseder:
Assigned To: mark.dickinson Nosy List: benjamin.peterson, ezio.melotti, mark.dickinson, mfxmfx, rhettinger
Priority: release blocker Keywords: patch

Created on 2009-06-24 10:51 by mfxmfx, last changed 2009-06-25 11:31 by mfxmfx. This issue is now closed.

Files
File name Uploaded Description Edit
issue6334.patch mark.dickinson, 2009-06-24 14:47
Messages (8)
msg89660 - (view) Author: Markus F.X.J. Oberhumer (mfxmfx) Date: 2009-06-24 10:51
Please note that the correct answer is 25, and the last element is missing !

This bug does not show on 64-bit versions (but 46337**2 is near 2**31).

~Markus


C:\Python31>python
Python 3.1rc2 (r31rc2:73414, Jun 13 2009, 16:43:15) [MSC v.1500 32 bit
(Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> len(list(range(46337**2, 46349**2, 46337)))
24

C:\Python30>python.exe
Python 3.0.1 (r301:69561, Feb 13 2009, 20:04:18) [MSC v.1500 32 bit
(Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> len(list(range(46337**2, 46349**2, 46337)))
24
msg89661 - (view) Author: Ezio Melotti (ezio.melotti) * (Python committer) Date: 2009-06-24 11:27
Simpler test case:
Py2.6:
>>> n = 46349**2
>>> n
2148229801L
>>> range(n-10, n, 3)
[2148229791L, 2148229794L, 2148229797L, 2148229800L]

Py3.0:
>>> n = 46349**2
>>> n
2148229801
>>> list(range(n-10, n, 3))
[2148229791, 2148229794, 2148229797]
msg89665 - (view) Author: Mark Dickinson (mark.dickinson) * (Python committer) Date: 2009-06-24 13:56
The length calculation in range_iter in Objects/rangeobject.c is 
incorrect, when using a longrangeiterobject.  The length is computed
as:  (stop - start)//step.  It should be ceiling((stop-start)/step), or
1 + (stop - start - 1)//step, provided that start <= stop and step > 0.
It's not clear to me right now whether there may also be problems with 
negative steps, and with cases where start < stop, etc.

I think this is serious enough to be considered a release blocker for 3.1;  
I'm working on a patch, and will post it later today.
msg89667 - (view) Author: Mark Dickinson (mark.dickinson) * (Python committer) Date: 2009-06-24 14:47
Here's a patch for py3k.

There are also a whole bunch of tests that are commented
out in BuiltinTest.test_range in Lib/test/test_builtin.py.
Some of those tests fail with the current py3k;  with this
patch applied, they all pass except the one involving 'badzero'.
msg89669 - (view) Author: Benjamin Peterson (benjamin.peterson) * (Python committer) Date: 2009-06-24 18:21
The patch looks good. Please apply.
msg89670 - (view) Author: Mark Dickinson (mark.dickinson) * (Python committer) Date: 2009-06-24 18:37
Applied to py3k in r73547.  Will backport to 3.0.
msg89674 - (view) Author: Mark Dickinson (mark.dickinson) * (Python committer) Date: 2009-06-24 19:24
Backported to release30-maint branch in r73549.

Thanks for catching this, Markus!
msg89702 - (view) Author: Markus F.X.J. Oberhumer (mfxmfx) Date: 2009-06-25 11:31
Many thanks for your quick fix! ~Markus
History
Date User Action Args
2009-06-25 11:31:15mfxmfxsetmessages: + msg89702
2009-06-24 19:24:52mark.dickinsonsetstatus: open -> closed
resolution: fixed
messages: + msg89674

stage: commit review -> resolved
2009-06-24 18:37:50mark.dickinsonsetmessages: + msg89670
versions: - Python 3.1
2009-06-24 18:21:05benjamin.petersonsetnosy: + benjamin.peterson
messages: + msg89669
2009-06-24 15:11:37mark.dickinsonsetstage: commit review
2009-06-24 14:47:02mark.dickinsonsetfiles: + issue6334.patch
keywords: + patch
messages: + msg89667
2009-06-24 13:56:48mark.dickinsonsetpriority: release blocker

nosy: + rhettinger
messages: + msg89665

assignee: mark.dickinson
2009-06-24 12:57:51pitrousetnosy: + mark.dickinson
2009-06-24 11:27:43ezio.melottisetnosy: + ezio.melotti
messages: + msg89661
2009-06-24 10:51:41mfxmfxcreate