On Mar 27, 2009, at 2:16 AM, Dag Sverre Seljebotn wrote:
> Stefan Behnel wrote:
>> Hi,
>>
>> now that we can guarantee Python semantics for the optimised for-
>> in-range
>> loop, should we enable the optimisation also when the loop
>> variable is not
>> explicitly typed, but when the range is constant and clearly
>> within int bounds?
>
> If this is done, I'd go even further and always do it. At least under
> Python 2:
>
>>>> for i in xrange(10**90): pass
> ...
> Traceback (most recent call last):
> File "<stdin>", line 1, in <module>
> OverflowError: long int too large to convert to int
>
> But I really thing that range() is such a common use, and super-
> ints so
> seldom, that I'd propose this as the one place it would make sense to
> break Python compatability also if Py3 fixes this (but keep a
> cython.bigrange which isn't optimized -- Sage has a corresponding
> srange
> I think).
>>> range(10**30, 10**30+10)
[1000000000000000000000000000000L, 1000000000000000000000000000001L,
1000000000000000000000000000002L, 1000000000000000000000000000003L,
1000000000000000000000000000004L, 1000000000000000000000000000005L,
1000000000000000000000000000006L, 1000000000000000000000000000007L,
1000000000000000000000000000008L, 1000000000000000000000000000009L]
but xrange is buggy to not be able to handle this (IMHO).
>> We might consider waiting with these things until we have flow
>> analysis in
>> place to make sure the loop variable isn't assigned non-int values
>> inside
>> the loop, but I doubt that this will be a common case.
>
> My instinct is to wait until we can start implementing some kind of
> simplistic type inference transform, with this as the first simple
> case
> to deal with, rather than specific code for the for-in-range. That
> would
> depend on flow analysis though.
>
> So my instinct is to wait, but practicality might push this special
> case
> ahead as you say. I'm not sure.
I felt the same, but on the other hand it is a super common case.
def do_range(N):
for i in range(N):
pass
def do_from(N):
for i from 0 <= i < N:
pass
sage: time do_range(10**7)
CPU times: user 0.44 s, sys: 0.05 s, total: 0.49 s
Wall time: 0.49 s
sage: time do_from(10**7)
CPU times: user 0.15 s, sys: 0.00 s, total: 0.15 s
Wall time: 0.15 s
seems to justify it.
- Robert
_______________________________________________
Cython-dev mailing list
[email protected]
http://codespeak.net/mailman/listinfo/cython-dev
