|
|
|
|
|
|
| Author |
Message |
Paul Boddie
*nix forums Guru Wannabe
Joined: 20 Feb 2005
Posts: 222
|
 Posted: Fri Jul 21, 2006 1:22 pm Post subject:
Re: range() is not the best way to check range?
|
|
|
Antoon Pardon wrote:
[Subclasses of list or slice for ranges]
| Quote: | Except that if you write your own class from scratch, you can't use
it as a slice. For a language that is supposed to be about duck typing
I find it strange that if I make my own class with a start, stop and
step attribute, that python barfs on it when I want to use it as a
slice.
|
[s2 has start, stop, step...]
| Quote: | lst[s2]
Traceback (most recent call last):
File "<stdin>", line 1, in ?
TypeError: list indices must be integers
|
In fact, the duck typing seems only to really work outside the
interpreter and the various accompanying built-in classes. Consider a
class similar to the one you defined with the name myslice (for
clarity) and with the apparently necessary indices method; consider it
used as follows:
| Quote: | range(0, 10)[myslice(1, 5, 2)]
Traceback (most recent call last): |
File "<stdin>", line 1, in ?
TypeError: list indices must be integers
Here, we start to believe that only traditional index or slice notation
will work. However, we did come across the built-in slice class before;
consider this:
| Quote: | range(0, 10)[slice(1, 5, 2)]
[1, 3] |
Regardless of whether myslice inherits from object or not, there's no
persuading the interpreter that it is a genuine slice, and remember
that we can't subclass slice (for some reason unknown). So, it would
appear that the interpreter really wants instances from some specific
set of types (presumably discoverable by looking at list_subscript in
listobject.c) rather than some objects conforming to some interface or
protocol, and perhaps it is implemented this way for performance
reasons.
In any case, in the core of Python some types/classes are more equal
than others, and for whatever reason the duck typing breaks down - a
case of "malbik endar" [1] that you just have to be aware of, I
suppose.
Paul
[1] http://www.sciamanna.com/island/pop/2004_07_13/280_malbik_endar.htm |
|
| Back to top |
|
 |
Antoon Pardon
*nix forums Guru
Joined: 21 Feb 2005
Posts: 483
|
| Posted: Fri Jul 21, 2006 12:14 pm Post subject:
Re: range() is not the best way to check range?
|
|
|
On 2006-07-20, Paul Boddie <paul@boddie.org.uk> wrote:
| Quote: | Alex Martelli wrote:
Paul Boddie <paul@boddie.org.uk> wrote:
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).
You'd also have to override just about every mutating method to switch
back to a "normal" __contains__ (or change self's type on the fly) -- a
pretty heavy price to pay.
A subclass of list is probably a bad idea in hindsight, due to various
probable requirements of it actually needing to be a list with all its
contents, whereas we wanted to avoid having anything like a list around
until the contents of this "lazy list" were required by the program. If
we really wanted to subclass something, we could consider subclassing
the slice class/type, but that isn't subclassable in today's Python for
some reason, and it doesn't really provide anything substantial,
anyway. However, Python being the language it is, an appropriately
behaving class is quite easily written from scratch.
|
Except that if you write your own class from scratch, you can't use
it as a slice. For a language that is supposed to be about duck typing
I find it strange that if I make my own class with a start, stop and
step attribute, that python barfs on it when I want to use it as a
slice.
| Quote: | class sl(object):
.... def __init__(self, start = None, stop = None, step = None): |
.... self.start = start
.... self.stop = stop
.... self.step = step
....
| Quote: | lst = range(20)
s1 = slice(3,13)
s2 = sl(3,13)
s1.start
3
s2.start
3
s1.stop
13
s2.stop
13
s1.step
s2.step
lst[s1]
[3, 4, 5, 6, 7, 8, 9, 10, 11, 12]
lst[s2]
Traceback (most recent call last): |
File "<stdin>", line 1, in ?
TypeError: list indices must be integers
--
Antoon Pardon |
|
| Back to top |
|
|
Alex Martelli
*nix forums Guru
Joined: 19 Feb 2005
Posts: 955
|
| Posted: Thu Jul 20, 2006 3:41 pm Post subject:
Re: range() is not the best way to check range?
|
|
|
Paul Boddie <paul@boddie.org.uk> wrote:
| Quote: | Alex Martelli wrote:
Paul Boddie <paul@boddie.org.uk> wrote:
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).
You'd also have to override just about every mutating method to switch
back to a "normal" __contains__ (or change self's type on the fly) -- a
pretty heavy price to pay.
A subclass of list is probably a bad idea in hindsight, due to various
probable requirements of it actually needing to be a list with all its
contents, whereas we wanted to avoid having anything like a list around
until the contents of this "lazy list" were required by the program. If
we really wanted to subclass something, we could consider subclassing
the slice class/type, but that isn't subclassable in today's Python for
some reason, and it doesn't really provide anything substantial,
anyway. However, Python being the language it is, an appropriately
behaving class is quite easily written from scratch.
|
Nevertheless, that class will still need to implement every single
method of the list type; making it a subclass of list has some advantage
in that every such implementation of a method can basically fill the
real list, self.__class__=list, and leave all the rest, forevermore
(explicitly here, implicitly in the future), to class list. Performance
should be much better than by working off semi-deprecated UserList.
A "hook method" __mutator__ (ideally called _before_ in this case), as I
was proposing (for 2.6 or later), would make such approaches way easier
and handier (and would help with most use cases I can think of for
subclassing list, dict or set).
Alex |
|
| Back to top |
|
|
Paul Boddie
*nix forums Guru Wannabe
Joined: 20 Feb 2005
Posts: 222
|
| Posted: Thu Jul 20, 2006 3:25 pm Post subject:
Re: range() is not the best way to check range?
|
|
|
Alex Martelli wrote:
| Quote: | Paul Boddie <paul@boddie.org.uk> wrote:
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).
You'd also have to override just about every mutating method to switch
back to a "normal" __contains__ (or change self's type on the fly) -- a
pretty heavy price to pay.
|
A subclass of list is probably a bad idea in hindsight, due to various
probable requirements of it actually needing to be a list with all its
contents, whereas we wanted to avoid having anything like a list around
until the contents of this "lazy list" were required by the program. If
we really wanted to subclass something, we could consider subclassing
the slice class/type, but that isn't subclassable in today's Python for
some reason, and it doesn't really provide anything substantial,
anyway. However, Python being the language it is, an appropriately
behaving class is quite easily written from scratch.
Paul |
|
| Back to top |
|
|
Alex Martelli
*nix forums Guru
Joined: 19 Feb 2005
Posts: 955
|
| Posted: Thu Jul 20, 2006 3:14 pm Post subject:
Re: range() is not the best way to check range?
|
|
|
Paul Boddie <paul@boddie.org.uk> wrote:
| Quote: | 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).
|
You'd also have to override just about every mutating method to switch
back to a "normal" __contains__ (or change self's type on the fly) -- a
pretty heavy price to pay.
I have often noticed that subclassing list, dict and maybe set has this
kind of issue: the need to track every possible change to the object.
Maybe a good mechanism to have for the purpose would be to add to
mutable types a "hook" method, say __mutator__, which gets called either
right before or right after any mutating method (there are different
tradeoffs for before-calls and after-calls), presumably passing along
the *a and **k for generality (although it might be faster for the base
case to avoid that); the base types would have a no-op implementation,
but subtypes could easily override just the hook to facilitate their
task of maintaining extra state (could be as little as a per-instance
flag recording whether the object is guaranteed to be still "pristine").
At C level, that might be an extra slot tp_mutator, left NULL in base
types to indicate "no mutator-hook method implemented here".
Like any other addition of, or change to, functionality, this would of
course be a proposal for 2.6, since 2.5 is feature-frozen now.
Alex |
|
| Back to top |
|
|
Dan Bishop
*nix forums addict
Joined: 24 Feb 2005
Posts: 91
|
| Posted: Wed Jul 19, 2006 5:33 pm Post subject:
Re: range() is not the best way to check range?
|
|
|
Paul Boddie wrote:
| Quote: | John Machin wrote:
On 19/07/2006 1:05 AM, Dan Bishop wrote:
xrange already has __contains__.
As pointed out previously, xrange is a function and one would not expect
it to have a __contains__ method.
Well, you pointed out that range is a function, but xrange seems to be
a type...
xrange
type 'xrange'
dir(xrange)
['__class__', '__delattr__', '__doc__', '__getattribute__',
'__getitem__', '__hash__', '__init__', '__iter__', '__len__',
'__new__', '__reduce__', '__reduce_ex__', '__repr__', '__reversed__',
'__setattr__', '__str__']
No __contains__ method, though, at least in 2.4.1.
The objects returned by xrange do not (according to my reading of the
2.4.3 version of Objects/rangeobject.c) have a __contains__ method.
As confirmed by the above evidence.
I find it difficult to believe that an inefficient __contains__ has been
implemented since.
So do I. As you go on to say, the usual sequence traversal mechanisms
are probably used to support the "in" operator. Whether it's a pressing
matter to add support for a more efficient mechanism depends on how
often people want to use ranges in the way described. Perhaps I'll
write a patch - who knows? 
|
My mistake. I should have looked at dir(xrange) before posting.
But the point remains that xrange's "implicit __contains__" runs in
linear time when a constant-time algorithm exists. |
|
| Back to top |
|
|
Simon Forman
*nix forums addict
Joined: 22 Jun 2006
Posts: 83
|
| Posted: Wed Jul 19, 2006 4:50 am Post subject:
Re: range() is not the best way to check range?
|
|
|
tac-tics wrote:
| Quote: | Simon Forman wrote:
To me, and perhaps others, "T =
set(xrange(0, 10000, 23))" and "n in T" are somewhat easier to read
and write than "not n % 23 and 0 <= n < 10000", YMMV.
Eh? How is the first easier to read than the second?? You have a nested
function call in the first!
|
I find the first form more immediately comprehensible than the latter.
I know what xrange() does, and I know what set() does, and "nested
function calls" give me no trouble, whereas the latter form with a
modulus, negation, and comparisons would take me a bit longer both to
compose and/or understand.
If this is not the case for you then by all means please disregard my
posting. YMMV.
| Quote: |
Regardless, testing if a member is part of a ranged set is always going
to be slower.
|
Yes. Roughly 0.0000001 seconds slower on my five year old computer.
I'm not worried.
| Quote: | It's the nature of what you're doing. Building a set and
then searching it takes much longer than a single modulus and
subtraction (which is all an integer comparison is).
|
Building the set, yes, but searching the set is very close to the same
speed, even for rather large sets. If you were performing the search
30000 times (like in the OP) it would only take about three thousandths
of a second longer, and that's on my old slow computer.
If I were doing this a thousand times more often, or on a range of a
million or more, or in production code, or with ranges that changed
often, then I would certainly take the time to write out the latter
form.
Peace,
~Simon |
|
| Back to top |
|
|
Paul Boddie
*nix forums Guru Wannabe
Joined: 20 Feb 2005
Posts: 222
|
| Posted: Tue Jul 18, 2006 10:35 pm Post subject:
Re: range() is not the best way to check range?
|
|
|
John Machin wrote:
| Quote: | On 19/07/2006 1:05 AM, Dan Bishop wrote:
xrange already has __contains__.
As pointed out previously, xrange is a function and one would not expect
it to have a __contains__ method.
|
Well, you pointed out that range is a function, but xrange seems to be
a type...
| Quote: | xrange
type 'xrange'
dir(xrange)
['__class__', '__delattr__', '__doc__', '__getattribute__', |
'__getitem__', '__hash__', '__init__', '__iter__', '__len__',
'__new__', '__reduce__', '__reduce_ex__', '__repr__', '__reversed__',
'__setattr__', '__str__']
No __contains__ method, though, at least in 2.4.1.
| Quote: | The objects returned by xrange do not (according to my reading of the
2.4.3 version of Objects/rangeobject.c) have a __contains__ method.
|
As confirmed by the above evidence.
| Quote: | I find it difficult to believe that an inefficient __contains__ has been
implemented since.
|
So do I. As you go on to say, the usual sequence traversal mechanisms
are probably used to support the "in" operator. Whether it's a pressing
matter to add support for a more efficient mechanism depends on how
often people want to use ranges in the way described. Perhaps I'll
write a patch - who knows? ;-)
Paul |
|
| Back to top |
|
|
John Machin
*nix forums Guru
Joined: 19 Feb 2005
Posts: 608
|
| Posted: Tue Jul 18, 2006 9:45 pm Post subject:
Re: range() is not the best way to check range?
|
|
|
On 19/07/2006 1:05 AM, Dan Bishop wrote:
| Quote: | 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__.
|
As pointed out previously, xrange is a function and one would not expect
it to have a __contains__ method.
The objects returned by xrange do not (according to my reading of the
2.4.3 version of Objects/rangeobject.c) have a __contains__ method.
I find it difficult to believe that an inefficient __contains__ has been
implemented since.
Perhaps you are unaware that the mere fact that an object supports the
"in" operation does not mean that this support is provided by a
__contains__ method. The following section of the manual may help:
"""
The membership test operators (in and not in) are normally implemented
as an iteration through a sequence. However, container objects can
supply the following special method with a more efficient
implementation, which also does not require the object be a sequence.
__contains__( self, item)
Called to implement membership test operators. Should return true
if item is in self, false otherwise. For mapping objects, this should
consider the keys of the mapping rather than the values or the key-item
pairs.
""" |
|
| Back to top |
|
|
tactics40@gmail.com
*nix forums beginner
Joined: 13 Jun 2006
Posts: 33
|
| Posted: Tue Jul 18, 2006 9:34 pm Post subject:
Re: range() is not the best way to check range?
|
|
|
Simon Forman wrote:
| Quote: | To me, and perhaps others, "T =
set(xrange(0, 10000, 23))" and "n in T" are somewhat easier to read
and write than "not n % 23 and 0 <= n < 10000", YMMV.
|
Eh? How is the first easier to read than the second?? You have a nested
function call in the first!
Regardless, testing if a member is part of a ranged set is always going
to be slower. It's the nature of what you're doing. Building a set and
then searching it takes much longer than a single modulus and
subtraction (which is all an integer comparison is). |
|
| Back to top |
|
|
Summercoolness@gmail.com
*nix forums beginner
Joined: 01 Jul 2006
Posts: 5
|
| Posted: Tue Jul 18, 2006 9:25 pm Post subject:
Re: range() is not the best way to check range?
|
|
|
Summercoolness@gmail.com wrote:
| Quote: | it seems that range() can be really slow:
if i in range (0, 10000):
|
My original use was like this:
if i in range (iStart, iEnd):
listData.append(a)
in which iStart is 1000 and iEnd is 1008
so in that case, the program ran fine...
but later on, i wanted to include all data, so I relaxed the range by
setting iStart to 0 and iEnd to 9999 and later on i found that the
program was slow due to this.
So looks like the usage of
if sDay in ("Tue", "Wed", "Thu"):
is more like good use of "in a list" but in range(0,10000) will be a
big search in a list. |
|
| Back to top |
|
|
Simon Forman
*nix forums addict
Joined: 22 Jun 2006
Posts: 83
|
| Posted: Tue Jul 18, 2006 8:28 pm Post subject:
Re: range() is not the best way to check range?
|
|
|
K.S.Sreeram wrote:
| Quote: | Simon Forman wrote:
Nick Craig-Wood wrote:
Sets are pretty fast too, and have the advantage of flexibility in
that you can put any numbers in you like
I know this is self-evident to most of the people reading this, but I
thought it worth pointing out that this is a great way to test
membership in range(lo, hi, step) without doing "the necessary
algebra".
i.e. n in set(xrange(0, 10000, 23)) ...
This is very very misleading... here are some timings :
|
Yes it is. I'm sorry about that.
| Quote: | python -mtimeit "n=5000" "n in set(xrange(0,10000))"
1000 loops, best of 3: 1.32 msec per loop
python -mtimeit "n=5000" "n in xrange(0,10000)"
1000 loops, best of 3: 455 usec per loop
python -mtimeit "n=5000" "0 <= n < 10000"
1000000 loops, best of 3: 0.217 usec per loop
sets are fast only if you create them *once* and use them again and
again. even in that case, the sets use up O(n) memory.
|
That's what I meant. But I didn't state it clearly.
One of the things I like most about python is that it allows you to
specify the problem that you want to solve without a great deal of
difficulty as to *how* to specify it. To me, and perhaps others, "T =
set(xrange(0, 10000, 23))" and "n in T" are somewhat easier to read
and write than "not n % 23 and 0 <= n < 10000", YMMV.
In the given case a set of ~(10000 / 23) ints would not usually be too
burdensome on ram, and the code runs close to the same speed as
compared to the direct calculation:
from timeit import Timer
times = 100000
Max = 10000
n = 5000
T = set(xrange(0, Max, 23))
s1 = 'n in T'
s2 = 'not n %% 23 and 0 <= n < %s' % Max
setup = 'from __main__ import n, T'
S1 = Timer(s1, setup).repeat(number=times)
S2 = Timer(s2, setup).repeat(number=times)
print "%.3f usec/pass" % (1000000 * min(S1) / times)
print "%.3f usec/pass" % (1000000 * min(S2) / times)
On my machine this printed:
0.476 usec/pass
0.552 usec/pass
| Quote: |
with comparison operators, you don't need extra memory *and* there is no
pre-computation required.
|
When I set Max = 100000000 in the above test code there was serious
disk thrashing... ;-)
FWIW, in production code I would certainly use the comparison
operators. A kilobyte saved is a kilobyte earned.
Peace,
~Simon |
|
| Back to top |
|
|
bearophileHUGS@lycos.com
*nix forums Guru Wannabe
Joined: 19 Feb 2005
Posts: 198
|
| Posted: Tue Jul 18, 2006 8:11 pm Post subject:
Re: range() is not the best way to check range?
|
|
|
Dan Bishop:
| Quote: | 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?
|
I think this is a nice idea.
Bye,
bearophile |
|
| Back to top |
|
|
Grant Edwards
*nix forums Guru
Joined: 21 Feb 2005
Posts: 1227
|
| Posted: Tue Jul 18, 2006 5:56 pm Post subject:
Re: range() is not the best way to check range?
|
|
|
On 2006-07-18, Paul Boddie <paul@boddie.org.uk> wrote:
| Quote: | It's unclear what you're referring to as "the range".
The notion of something describing a range of values which can be
expanded to a list or, of relevance here, whose boundaries can be
tested efficiently.
Perhaps you're thinking of a slice? Somethign like
if (0:10000).contains(x):
|
I didn't mean to imply that would actually work, but I thought
maybe that's what you were proposing.
| Quote: | Did you mean...?
(0:10000) # SyntaxError
slice(0, 10000).contains(x) # AttributeError
3 in slice(0, 10000) # TypeError
Something like this might suffice if slice could have a __contains__
method or if people thought of slices as natural things to test
against.
|
A slice seems to me to be the obvious way to represent a finite
length algebraic sequence of integers. However, obvioiusness
is in the eye of the beholder since as you point out below to
the OP, a range() was the obvious way to it.
| Quote: | Perhaps we could ask the original questioner why they chose to
use range in such a way - it might indicate a background in
languages which encourage the construction of ranges and their
use in comparisons - although being told to RTFM may have
scared them off.
|
--
Grant Edwards grante Yow! Did I say I was a
at sardine? Or a bus???
visi.com |
|
| Back to top |
|
|
Dennis Lee Bieber
*nix forums Guru
Joined: 05 Mar 2005
Posts: 819
|
| Posted: Tue Jul 18, 2006 5:53 pm Post subject:
Re: range() is not the best way to check range?
|
|
|
On Tue, 18 Jul 2006 15:30:54 -0000, Grant Edwards <grante@visi.com>
declaimed the following in comp.lang.python:
| Quote: | Interesting point. Does the phrase "for pete's sake as god
intended" equate pete with god?
That's a bit of a promotion -- a quick google indicates that the |
"pete" in the phrase is a shortened form of "Saint Peter"...
--
Wulfraed Dennis Lee Bieber KD6MOG
wlfraed@ix.netcom.com wulfraed@bestiaria.com
HTTP://wlfraed.home.netcom.com/
(Bestiaria Support Staff: web-asst@bestiaria.com)
HTTP://www.bestiaria.com/ |
|
| Back to top |
|
|
Google
|
|
| Back to top |
|
|
|
|
The time now is Fri Nov 21, 2008 9:45 pm | All times are GMT
|
|
Discount Magazines | Mortgage Calculator | Mortgages | Turbo Tax software | Debt Consolidation
|
|
Copyright © 2004-2005 DeniX Solutions SRL
|
|
|
|
Other DeniX Solutions sites:
Unix/Linux blog |
electronics forum |
medicine forum |
science forum |
|
|
Privacy Policy
|
Powered by phpBB © 2001, 2005 phpBB Group
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
Forum index
»
Programming
»
python
