range() is not the best way to check range?

[Summercoolness]

it seems that range() can be really slow:

the following program will run, and the last line shows how long it ran
for:

import time

startTime = time.time()

a = 1.0
for i in range(0, 30000):
if i in range (0, 10000):
a += 1
if not i % 1000: print i

print a, " ", round(time.time () - startTime, 1), "seconds"
---------------------------------
the last line of output is
---------------------------------

10001.0 22.8 seconds

so if i change the line

if i in range (0, 10000):

to

if i >= 0 and i < 10000:

the the last line is

10001.0 0.2 seconds

so approximately, the program ran 100 times faster!

or is there an alternative use of range() or something similar that can
be as fast?

[Paul Boddie]

John Machin wrote:

On 18/07/2006 12:41 PM, Su************@ gmail.com wrote:

it seems that range() can be really slow:

[...]

Some things to try:
1a. Read what the manual has to say about the range() function ... what
does it produce?

Indeed. Still, the addition of a __contains__ method to range (and
xrange) would permit acceptable performance for the code given. Perhaps
this is a convenience worth considering for future Python releases.

Paul

[Andy Dingley]

Su************@ gmail.com wrote:

it seems that range() can be really slow:

if i in range (0, 10000):

RTFM on range()

You're completely mis-using it here, using it with an if ... in ...
test. The purpose of range() in Python is as loop control, not
comparisons! It's not a SQL BETWEEN statement.

Although you _can_ do this (you've done it!) you've also found that
it's slow. Many people would argue that even using range() for loop
control is unusably slow.

[Leif K-Brooks]

Grant Edwards wrote:

Using xrange as somebody else suggested is also insane.

Sorry about that, I somehow got the misguided notion that xrange defines
its own __contains__, so that it would be about the same speed as using
comparison operators directly. I figured the OP might have a better
reason for wanting to use range() than his post mentioned -- perhaps the
range to check was being passed from a function, and it would be easier
to pass an object than a tuple of lower and upper bound -- but since
xrange does looping for a membership test, my suggestion was indeed insane.

[John Machin]

On 18/07/2006 7:22 PM, Paul Boddie wrote:

John Machin wrote:

>On 18/07/2006 12:41 PM, Su************@ gmail.com wrote:

>>it seems that range() can be really slow:

[...]

>Some things to try:
1a. Read what the manual has to say about the range() function ... what
does it produce?

Indeed. Still, the addition of a __contains__ method to range (and
xrange) would permit acceptable performance for the code given. Perhaps
this is a convenience worth considering for future Python releases.

range() and xrange() are functions. You are suggesting that 2
*functions* should acquire a __contains__ method each? I trust not.

Perhaps you meant that the acquisitors should be the objects that those
functions return.

range() returns a list. Lists already have a __contains__ method. It's
been getting a fair old exercising in the last few hours, but here we go
again:

>python -mtimeit -s"x=range(30000 )" "x.__contains__ (40000)"

1000 loops, best of 3: 1.09 msec per loop

>python -mtimeit -s"x=range(30000 )" "40000 in x"

1000 loops, best of 3: 1.09 msec per loop

>python -mtimeit -s"x=range(30000 )" "x.__contains__ (1)"

1000000 loops, best of 3: 0.434 usec per loop

>python -mtimeit -s"x=range(30000 )" "1 in x"

1000000 loops, best of 3: 0.137 usec per loop

A __contains__ method for xrange objects? The case of x in xrange(lo,
hi) is met by lo <= x < hi. IMHO, anyone who wants x in xrange(lo, hi,
step) should be encouraged to do the necessary algebra themselves; I
wouldn't suggest that any core dev time be wasted on implementing such
folderol.

In any case, isn't the *whole* xrange gizmoid on GvR's I-wish-I-hadn't list?

Cheers,
John

[Paul Boddie]

John Machin wrote:

>
range() and xrange() are functions. You are suggesting that 2
*functions* should acquire a __contains__ method each? I trust not.

Well, range is a function in the current implementation, although its
usage is similar to that one would get if it were a class, particularly
a subclass of list or one providing a list-style interface. With such a
class, you could provide a __contains__ method which could answer the
question of what the range contains based on the semantics guaranteed
by a range (in contrast to a normal list).

Perhaps you meant that the acquisitors should be the objects that those
functions return.

The whole point was to avoid expanding the range into a list.

[...]

A __contains__ method for xrange objects? The case of x in xrange(lo,
hi) is met by lo <= x < hi. IMHO, anyone who wants x in xrange(lo, hi,
step) should be encouraged to do the necessary algebra themselves; I
wouldn't suggest that any core dev time be wasted on implementing such
folderol.

Sure, you could always implement your own class to behave like an
existing range and to implement the efficient semantics proposed above.

In any case, isn't the *whole* xrange gizmoid on GvR's I-wish-I-hadn't list?

Yes, he wants range to return an iterator, just like xrange more or
less does now. Given that xrange objects support __getitem__, unlike a
lot of other iterators (and, of course, generators), adding
__contains__ wouldn't be much of a hardship. Certainly, compared to
other notational conveniences bounced around on the various development
lists, this one would probably provide an order of magnitude
improvement on the usual bang per buck development ratio.

Paul

[Stefan Behnel]

Andy Dingley wrote:

The purpose of range() in Python is as loop control,

No, the purpose of range() is to create a list, as the docs state.

http://docs.python.org/lib/built-in-funcs.html

"""
range(...) - This is a versatile function to create lists containing
arithmetic progressions.
"""

Stefan

[Dan Bishop]

Paul Boddie wrote:

Yes, he wants range to return an iterator, just like xrange more or
less does now. Given that xrange objects support __getitem__, unlike a
lot of other iterators (and, of course, generators), adding
__contains__ wouldn't be much of a hardship. Certainly, compared to
other notational conveniences bounced around on the various development
lists, this one would probably provide an order of magnitude
improvement on the usual bang per buck development ratio.

xrange already has __contains__. The problem is, it's implemented by a
highly-inefficient sequential search. Why not modify it to merely
check the bounds and (value - start) % step == 0?

[Grant Edwards]

On 2006-07-18, tac-tics <ta*******@gmai l.comwrote:

Grant Edwards wrote:

>for pete's sake use the comparison operator like god intended.

if 0 <= i <= 10000:

I'm assuming you used Python's compound comparison as opposed to the
C-style of and'ing two comparisons together to emphasize the fact it is
god's chosen way of doing this ;-)

Exactly!

--
Grant Edwards grante Yow! HUGH BEAUMONT died
at in 1982!!
visi.com

[Grant Edwards]

On 2006-07-18, Marc 'BlackJack' Rintsch <bj****@gmx.net wrote:

In <11************ **********@h48g 2000cwc.googleg roups.com>, tac-tics
wrote:

>Grant Edwards wrote:

>>for pete's sake use the comparison operator like god intended.

if 0 <= i <= 10000:

I'm assuming you used Python's compound comparison as opposed to the
C-style of and'ing two comparisons together to emphasize the fact it is
god's chosen way of doing this ;-)

Pete doesn't like to be called god in public. ;-)

Interesting point. Does the phrase "for pete's sake as god
intended" equate pete with god?

It's possible that pete is not god and yet god's intentions are
in pete's best interest, so something could be "for pete's
sake" and "as god intended" without pete being god.

That said, "for pete's sake" is probably a just an cleaned up
version of "for god's sake", so I probably did call pete god.

--
Grant Edwards grante Yow! This PORCUPINE knows
at his ZIPCODE... And he has
visi.com "VISA"!!

[Grant Edwards]

On 2006-07-18, Paul Boddie <pa**@boddie.or g.ukwrote:

John Machin wrote:

>>
range() and xrange() are functions. You are suggesting that 2
*functions* should acquire a __contains__ method each? I trust
not.

Well, range is a function in the current implementation,
although its usage is similar to that one would get if it were
a class, particularly a subclass of list or one providing a
list-style interface. With such a class, you could provide a
__contains__ method which could answer the question of what
the range contains based on the semantics guaranteed by a
range (in contrast to a normal list).

>Perhaps you meant that the acquisitors should be the objects
that those functions return.

The whole point was to avoid expanding the range into a list.

It's unclear what you're referring to as "the range".

Perhaps you're thinking of a slice? Somethign like

if (0:10000).conta ins(x):

--
Grant Edwards grante Yow! Make me look like
at LINDA RONSTADT again!!
visi.com