Re: "I know I'm going to get flak for bringing this up this old issue, but
remember when you used to write a for-loop and it involved creating an actual
list of N integers from 0 to N-1 in order to iterate through them? Crazy.
But that has long been fixed - or so I thought. When I wrote, today:
Chris Angelico wrote:
> On Thu, Aug 4, 2011 at 4:01 AM, Steven D'Aprano
> wrote:
>> a, b = divmod(n, i)
>> if b == 0:
>> total += a+i
>>
>
> Wouldn't this fail on squares? It happens to give correct results as
> far as I've checked; no square up to 10,000 is called perfect, and
> there are no pe
On Thu, Aug 4, 2011 at 4:01 AM, Steven D'Aprano
wrote:
> a, b = divmod(n, i)
> if b == 0:
> total += a+i
>
Wouldn't this fail on squares? It happens to give correct results as
far as I've checked; no square up to 10,000 is called perfect, and
there are no perfect squares
harrismh777 wrote:
> def perf(n):
> sum = 0
> for i in range(1, n):
> if n % i == 0:
> sum += i
> return sum == n
A more effective way to speed that up is with a better algorithm:
def isperfect(n):
if n < 2: return False
total = 1
for i in range(
On Tue, Aug 2, 2011 at 3:45 PM, Steven D'Aprano
wrote:
> (But don't make the mistake of doing what I did, which was to attempt to
> produce range(29000) in Python 2. After multiple *hours* of swapping, I
> was finally able to kill the Python process and get control of my PC again.
> Sigh.)
>
harrismh777 wrote:
> The following is intended as a helpful small extension to the xrange()
> range() discussion brought up this past weekend by Billy Mays...
>
> With Python2 you basically have two ways to get a range of numbers:
> range() , which returns a list, and
>xrange() , which r
On Tue, Aug 2, 2011 at 10:05 AM, Peter Otten <[email protected]> wrote:
> i/2 returns a float in Python 3; you should use i//2 for consistency.
>
And I forgot to make this change before doing my tests. Redoing the
Python 3 ones with // quite drastically changes things!
3.2 (r32:88445, Feb 20 2011,
On Tue, Aug 2, 2011 at 10:20 AM, Stefan Behnel wrote:
> What version of Py3 were you using? If you used the latest, maybe even the
> latest hg version, you will notice that that's substantially faster for
> integers than, e.g. 3.1.x.
>
I just tried this out, using a slightly modified script but t
Am 02.08.2011 09:12 schrieb harrismh777:
The following is intended as a helpful small extension to the xrange()
range() discussion brought up this past weekend by Billy Mays...
With Python2 you basically have two ways to get a range of numbers:
range() , which returns a list, and
xrange() , whic
harrismh777, 02.08.2011 09:12:
With Python2 you basically have two ways to get a range of numbers:
range() , which returns a list, and
xrange() , which returns an iterator.
With Python3 you must use range(), which produces an iterator; while
xrange() does not exist at all (at least not on 3.2).
harrismh777 wrote:
> The following is intended as a helpful small extension to the xrange()
> range() discussion brought up this past weekend by Billy Mays...
>
> With Python2 you basically have two ways to get a range of numbers:
> range() , which returns a list, and
>xrange() , which r
harrismh777 wrote:
these will run on either Python2 or
> Python3... except that if you substitute xrange() for range() for
> Python2 they will throw an exception on Python3... doh.
if 'xrange' not in dir(__builtins__):
xrange = range
at the beginning of your program will fix that.
--
> > x = [0010, 0210]
>
> You do realize that this is octal, right?
It's unfortunate I choose that, the numbers go beyond octal
> len is undefined for integers. Perhaps you meant "len(str(x[1]))".
Yes sorry it was late at night :P
> You can, however, do this:
> >>> '%0*d' % (5, 123)
> '00123'
T
On May 9, 1:42 pm, yhvh <[EMAIL PROTECTED]> wrote:
> I want to generate a range with variable leading zeros
>
> x = [0010, 0210]
> padding = len(x[1])
>
> for j in range(x[0], x[1]):
> print (url).join('%0(pad)d(jj)'+'.jpg') %{'pad':padding, 'jj':j}
>
> This is syntactically incorrect, you can'
On May 8, 10:42 pm, yhvh <[EMAIL PROTECTED]> wrote:
> I want to generate a range with variable leading zeros
>
> x = [0010, 0210]
You do realize that this is octal, right?
> padding = len(x[1])
len is undefined for integers. Perhaps you meant "len(str(x[1]))".
> for j in range(x[0], x[1]):
>
In article <[EMAIL PROTECTED]>,
Colin J. Williams <[EMAIL PROTECTED]> wrote:
.
.
.
>Your point about iterators is well taken, but it seems that the range is
>used sufficiently frequently that some syntactic form would be helpf
Fredrik Lundh wrote:
> Colin J. Williams wrote:
>
>> One of the little irritants of Python is that the range syntax is rather
>> long-winded:
>> [Dbg]>>> range(3, 20, 6)
>> [3, 9, 15]
>> [Dbg]>>>
>> It would be nice if one could have something like 3:20:6.
>
> if you find yourself using range a
On 2006-11-10, Roberto Bonvallet <[EMAIL PROTECTED]> wrote:
> Colin J. Williams wrote:
>> One of the little irritants of Python is that the range syntax is rather
>> long-winded:
>> [Dbg]>>> range(3, 20, 6)
>> [3, 9, 15]
>> [Dbg]>>>
>> It would be nice if one could have something like 3:20:6.
>
>
Colin J. Williams wrote:
> One of the little irritants of Python is that the range syntax is rather
> long-winded:
> [Dbg]>>> range(3, 20, 6)
> [3, 9, 15]
> [Dbg]>>>
> It would be nice if one could have something like 3:20:6.
if you find yourself using range a lot, maybe you should check if you
Colin J. Williams wrote:
> One of the little irritants of Python is that the range syntax is rather
> long-winded:
> [Dbg]>>> range(3, 20, 6)
> [3, 9, 15]
> [Dbg]>>>
> It would be nice if one could have something like 3:20:6.
In that case, how would the parser know which colon terminates the
'for
23 Aug 2006 17:28:48 -0700, KraftDiner <[EMAIL PROTECTED]>:
> This is obvious... but how do I crop off the high order bits if
> necessary?
> a[0]&0x ?
min(a[0], 0x) ?
--
Felipe.
--
http://mail.python.org/mailman/listinfo/python-list
Terry Reedy wrote:
> "KraftDiner" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]
> >
> > So what type / class should one use to represent a 16 bit integers
> > (signed or unsigned)?
>
> For most purposes, Python just has integers, with 'small' ones (depending
> on the machine) handl
"KraftDiner" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
>
> So what type / class should one use to represent a 16 bit integers
> (signed or unsigned)?
For most purposes, Python just has integers, with 'small' ones (depending
on the machine) handled more efficiently. For specia
At Wednesday 23/8/2006 18:53, KraftDiner wrote:
> |>> import sys
> |>> sys.maxint
> 2147483647
>
So what type / class should one use to represent a 16 bit integers
(signed or unsigned)?
Plain int.
If you need the overflow at 32K/64K, try: x & 0x
Gabriel Genellina
Softlab SRL
Simon Forman wrote:
> KraftDiner wrote:
> > What is the range of a variable of type int()
> >
> > eg:
> > i = int()
> > print i.max() # 0x
> > print i.min() # 0x
> >
> > is it a signed 16 bit or 32 bit or is it unsigned 16 or 32...
> > I've noticed that it can be incremented into
KraftDiner wrote:
> What is the range of a variable of type int()
>
> eg:
> i = int()
> print i.max() # 0x
> print i.min() # 0x
>
> is it a signed 16 bit or 32 bit or is it unsigned 16 or 32...
> I've noticed that it can be incremented into a new class of type
> long...
|>> import
On 2006-07-23, Paul Boddie <[EMAIL PROTECTED]> wrote:
> Antoon Pardon wrote:
>>
>> Except that if you write your own class from scratch, you can't use
>> it as a slice.
>
> Correct, but we were actually discussing subclassing built-in classes
> for use as a replacement for range/xrange. :-)
I thin
Antoon Pardon wrote:
>
> Except that if you write your own class from scratch, you can't use
> it as a slice.
Correct, but we were actually discussing subclassing built-in classes
for use as a replacement for range/xrange. :-)
It may be "hard work" writing all those methods in a totally new
range
On 2006-07-21, Paul Boddie <[EMAIL PROTECTED]> wrote:
> 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 re
Paul Boddie wrote:
[...]
> 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 som
Antoon Pardon wrote:
>
[Subclasses of list or slice for ranges]
> 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, t
On 2006-07-20, Paul Boddie <[EMAIL PROTECTED]> wrote:
> Alex Martelli wrote:
>> Paul Boddie <[EMAIL PROTECTED]> 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
Paul Boddie <[EMAIL PROTECTED]> wrote:
> Alex Martelli wrote:
> > Paul Boddie <[EMAIL PROTECTED]> 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 p
Alex Martelli wrote:
> Paul Boddie <[EMAIL PROTECTED]> 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
> > cla
Paul Boddie <[EMAIL PROTECTED]> wrote:
> 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
Paul Boddie wrote:
> 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
tac-tics wrote:
> Simon Forman wrote:
> > To me, and perhaps others, "T =
> > set(xrange(0, 1, 23))" and "n in T" are somewhat easier to read
> > and write than "not n % 23 and 0 <= n < 1", YMMV.
>
> Eh? How is the first easier to read than the second?? You have a nested
> function call in
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...
On 19/07/2006 1:05 AM, Dan Bishop wrote:
> 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 b
Simon Forman wrote:
> To me, and perhaps others, "T =
> set(xrange(0, 1, 23))" and "n in T" are somewhat easier to read
> and write than "not n % 23 and 0 <= n < 1", YMMV.
Eh? How is the first easier to read than the second?? You have a nested
function call in the first!
Regardless, test
[EMAIL PROTECTED] wrote:
> it seems that range() can be really slow:
>
> if i in range (0, 1):
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
K.S.Sreeram wrote:
> 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
Dan Bishop:
> 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
--
http://mail.python.org/mailman/listinfo/
On 2006-07-18, Paul Boddie <[EMAIL PROTECTED]> wrote:
>> 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 thinkin
On 2006-07-18, Steve Holden <[EMAIL PROTECTED]> wrote:
>> 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.
>
> No, actually you called god pete ;-)
Well that's certainly wrong, because we all know god's name is
Howard.
Grant Edwards wrote:
>
> 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
Diez B. Roggisch wrote:
> 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 wor
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 te
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 t
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
Dan Bishop wrote:
> [EMAIL PROTECTED] wrote:
> > it seems that range() can be really slow:
> ...
> > if i in range (0, 1):
>
> This creates a 10,000-element list and sequentially searches it. Of
> course that's gonna be slow.
And you're doing it 3 times.
--
http://mail.python.org/m
Grant Edwards wrote:
> On 2006-07-18, Marc 'BlackJack' Rintsch <[EMAIL PROTECTED]> wrote:
>
>>In <[EMAIL PROTECTED]>, tac-tics
>>wrote:
>>
>>
>>>Grant Edwards wrote:
>>>
for pete's sake use the comparison operator like god intended.
if 0 <= i <= 1:
>>>
>>>I'm assuming you used
On 2006-07-18, Paul Boddie <[EMAIL PROTECTED]> wrote:
> 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
On 2006-07-18, Marc 'BlackJack' Rintsch <[EMAIL PROTECTED]> wrote:
> In <[EMAIL PROTECTED]>, tac-tics
> wrote:
>
>> Grant Edwards wrote:
>>> for pete's sake use the comparison operator like god intended.
>>>
>>> if 0 <= i <= 1:
>>
>> I'm assuming you used Python's compound comparison as op
On 2006-07-18, tac-tics <[EMAIL PROTECTED]> wrote:
> Grant Edwards wrote:
>> for pete's sake use the comparison operator like god intended.
>>
>> if 0 <= i <= 1:
>
> I'm assuming you used Python's compound comparison as opposed to the
> C-style of and'ing two comparisons together to emphasi
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
> ot
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.
"""
Stef
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
On 18/07/2006 7:22 PM, Paul Boddie wrote:
> John Machin wrote:
>> On 18/07/2006 12:41 PM, [EMAIL PROTECTED] 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?
>
> I
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
rea
[EMAIL PROTECTED] wrote:
> it seems that range() can be really slow:
> if i in range (0, 1):
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
John Machin wrote:
> On 18/07/2006 12:41 PM, [EMAIL PROTECTED] 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 ran
Grant Edwards <[EMAIL PROTECTED]> wrote:
> Creating and then searching a 10,000 element list to see if a
> number is between two other numbers is insane.
> Using xrange as somebody else suggested is also insane.
Aye to both
> If you want to know if a number is between two other numders,
> f
In <[EMAIL PROTECTED]>, tac-tics
wrote:
> Grant Edwards wrote:
>> for pete's sake use the comparison operator like god intended.
>>
>> if 0 <= i <= 1:
>
> I'm assuming you used Python's compound comparison as opposed to the
> C-style of and'ing two comparisons together to emphasize the fa
Grant Edwards wrote:
> for pete's sake use the comparison operator like god intended.
>
> if 0 <= i <= 1:
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 ;-)
--
htt
On 2006-07-18, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> 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, 3):
> if i in range (0, 100
[EMAIL PROTECTED] wrote:
> so if i change the line
> if i in range (0, 1):
> to
> if i >= 0 and i < 1:
[snip;]
> is there an alternative use of range() or something similar that can
> be as fast?
you've found that alternative yourself! just use the comparison operators...
in fact
On 18/07/2006 12:41 PM, [EMAIL PROTECTED] wrote:
> 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, 3):
> if i in range (0, 1):
>
Leif K-Brooks wrote:
> [EMAIL PROTECTED] wrote:
> > or is there an alternative use of range() or something similar that can
> > be as fast?
>
> You could use xrange:
>
> [EMAIL PROTECTED]:~$ python -m timeit -n1 "1 in range(1)"
> 1 loops, best of 3: 260 usec per loop
> [EMAIL PROTECTED]
[EMAIL PROTECTED] wrote:
> or is there an alternative use of range() or something similar that can
> be as fast?
You could use xrange:
[EMAIL PROTECTED]:~$ python -m timeit -n1 "1 in range(1)"
1 loops, best of 3: 260 usec per loop
[EMAIL PROTECTED]:~$ python -m timeit -n1 "1 in xr
[EMAIL PROTECTED] wrote:
> it seems that range() can be really slow:
...
> if i in range (0, 1):
This creates a 10,000-element list and sequentially searches it. Of
course that's gonna be slow.
--
http://mail.python.org/mailman/listinfo/python-list
On 15 May 2005 02:50:38 -0700, Xah Lee <[EMAIL PROTECTED]> wrote:
> Here's the Perl code.
Where did you learn to program? Its highly unlikely that a Perl
programer would ever write a range function as there is a built in
Perl function that does the same thing. If your intent is purely
accedemic
Xah Lee wrote:
> the previous posted solutions are badly botched.
> def Range(iMin, iMax=None, iStep=None):
[snip hideous code]
> # Thanks to Peter Hansen for a correction.
Ohmigod, he's only made it worse and he's blaming me for it. Shows what
I get for replying to a cross-posted troll messag
the previous posted solutions are badly botched.
Here's a better solution. Any further correction will appear on the
website instead. (http://xahlee.org/tree/tree.html)
Similar change needs to be made for the Perl code... Java code will
come tomorror.
By the way, the code from me are not expecte
Xah Lee wrote:
> Here's the Python solution.
> # implementation note: When iStep is a decimal, rounding error
> # accumulates. For example, the last item returned from
> # Range(0,18,0.3) is 17.7 not 18. A remedy is to turn iStep into a
> # fraction and do exact arithmetics, and possibly convert th
Here's the Python solution.
--
# -*- coding: utf-8 -*-
# Python
# http://xahlee.org/tree/tree.html
# Xah Lee, 2005-05
# implementation note: When iStep is a decimal, rounding error
# accumulates. For example, the last item returned from
# Range(0,18,0.3) is 17.7 not 18. A remedy is to tu
Here's the Perl code.
--
#! perl
# http://xahlee.org/tree/tree.html
# Xah Lee, 2005-05
#_ Range _ _ _ _
=pod
B
Range($iMax) generates the list [1, 2, ... , $iMax].
Range($iMin, $iMax) generates the list [$iMin, ... , $iMax].
Range($iMin, $iMax, $iStep) uses incr
77 matches
Mail list logo
