I think you are right, it's the assignment itself which is slow.
Merged loop is only a tad quicker.
On Thursday, September 8, 2016 at 6:04:41 PM UTC+1, Christian Gollwitzer wrote:
> > Why nested loops are so slow in Python? Is it because new contexts are
> > created?
> > For more details, see
> >
Am 08.09.16 um 12:20 schrieb Igor Kozin:
Why nested loops are so slow in Python? Is it because new contexts are created?
For more details, see
http://stackoverflow.com/questions/26611043/numpy-vs-cython-nested-loop-so-slow
http://stackoverflow.com/questions/39371021/efficient-loop-over-numpy-arra
On Thu, Sep 8, 2016 at 8:20 PM, Igor Kozin wrote:
> Why nested loops are so slow in Python? Is it because new contexts are
> created?
> For more details, see
> http://stackoverflow.com/questions/26611043/numpy-vs-cython-nested-loop-so-slow
> http://stackoverflow.com/questions/39371021/efficient-l
On Wed, Dec 10, 2014 at 9:01 AM, Ian Kelly wrote:
> This also seems perfectly natural:
>
> def len(iterable):
> return sum(1 for item in iterable)
>
> My observation is that seems strange to me that one standard sequence
operation should be supported for arbitrary iterators and the other not.
On Wed, Dec 10, 2014 at 1:21 AM, Peter Otten <__pete...@web.de> wrote:
>
> Ian Kelly wrote:
> > Huh, I wasn't even aware that membership tests worked on iterables with
no
> > __contains__ method. Seems odd to me that 'x in y' should be supported
but
> > not 'len(y)'.
>
> To me
>
> def contains(iter
Shiyao Ma wrote:
> Thanks guys.
>
> I was only aware of a limited iterables which themselves are iterators,
> e.g., the generator.
>
> Seems like its really a pitfall. Any glossary, list on the iterables that
> *might* exhaust themselves?
Iterables include:
- iterators
- sequences (e.g. lists,
Shiyao Ma wrote:
> Thanks guys.
>
> I was only aware of a limited iterables which themselves are iterators,
> e.g., the generator.
>
> Seems like its really a pitfall. Any glossary, list on the iterables that
> *might* exhaust themselves?
Usually the test
iterable is iter(iterable)
returns Tr
Thanks guys.
I was only aware of a limited iterables which themselves are iterators, e.g.,
the generator.
Seems like its really a pitfall. Any glossary, list on the iterables that
*might* exhaust themselves?
Regards.
--
https://mail.python.org/mailman/listinfo/python-list
Ian Kelly wrote:
> On Tue, Dec 9, 2014 at 11:30 PM, Chris Angelico wrote:
>> Are you sure it isn't? Your 'space' is an iterable cubic
>> cross-product. Your first loop checks (0,0,0) which is the first
>> element returned, and is thus fast... but it also *consumes* that
>> first element. The next
On Wed, 10 Dec 2014 17:53:05 +1100, Chris Angelico wrote:
> On Wed, Dec 10, 2014 at 5:44 PM, Steven D'Aprano
> wrote:
>> It would be nice if product iterators behaved like xrange() objects and
>> could perform "in" tests without exhausting the iterator, but they
>> don't. That's sad.
>
> It'd be
On 12/10/2014 1:53 AM, Chris Angelico wrote:
On Wed, Dec 10, 2014 at 5:44 PM, Steven D'Aprano wrote:
It would be nice if product iterators behaved like xrange() objects and
could perform "in" tests without exhausting the iterator, but they don't.
That's sad.
It'd be very difficult to do that
On Tue, Dec 9, 2014 at 11:30 PM, Chris Angelico wrote:
> Are you sure it isn't? Your 'space' is an iterable cubic
> cross-product. Your first loop checks (0,0,0) which is the first
> element returned, and is thus fast... but it also *consumes* that
> first element. The next time you test it, the e
On Wed, Dec 10, 2014 at 5:44 PM, Steven D'Aprano wrote:
> It would be nice if product iterators behaved like xrange() objects and
> could perform "in" tests without exhausting the iterator, but they don't.
> That's sad.
It'd be very difficult to do that in the general sense. But it should
be poss
On Wed, 10 Dec 2014 13:20:25 +0800, Shiyao Ma wrote:
> When doing nested loop, the very first iteration of the innermost loop
> ends ultimately slow.
>
> Let's the code speak.
>
> The following code is quite contrived. Actually it's derived from my
> 3d-dct script. The actual difference is way m
On Wed, Dec 10, 2014 at 4:20 PM, Shiyao Ma wrote:
> from itertools import product
> space_len = 580
> space = product(xrange(space_len), xrange(space_len), xrange(space_len))
>
> sparse_cloud = product(xrange(1000), xrange(1000), xrange(1000))
> for i, j, k in sparse_cloud:
> ts = timeit.defau
One thing to note, the logic of using "in" is not of concern here.
This is a *contrived* example, the problem is the slowness of the first
iteration.
--
https://mail.python.org/mailman/listinfo/python-list
Hi!
> leonardo writes:
how can i have it print a row of stars beside each number, like this?:
how many seconds?: 5
5 * * * * *
4 * * * *
3 * * *
2 * *
1 *
blast off!
--- snip ---
sec = int(input("How many seconds? "))
for i in range(0,sec):
print str(sec-i)+":"+" *"*(sec-i)
print
leonardo writes:
> how can i have it print a row of stars beside each number, like this?:
>
> how many seconds?: 5
> 5 * * * * *
> 4 * * * *
> 3 * * *
> 2 * *
> 1 *
> blast off!
You could use the repetition operator * since you have the number of
repetitions needed in i. Alternatively, consider
On Mon, 25 Feb 2013 23:46:11 +0100, leonardo wrote:
> hi everyone,
>
> i have the following program:
>
> import time count_timer = int(raw_input('how many seconds?: '))
> for i in range(count_timer, 0, -1):
> print i time.sleep(1)
> print 'blast off!'
>
>
> this is the result:
>
> how ma
thanks for the help, it works
Il 26/02/2013 10.58, Sven ha scritto:
Here's one solution
import time
count_timer = int(raw_input('how many seconds?: '))
for i in range(count_timer, 0, -1):
||print i,
print "*" * i
time.sleep(1)
print 'blast off!'
On 25 February 2013 22:46, leonardo
Here's one solution
import time
count_timer = int(raw_input('how many seconds?: '))
for i in range(count_timer, 0, -1):
print i,
print "*" * i
time.sleep(1)
print 'blast off!'
On 25 February 2013 22:46, leonardo wrote:
> hi everyone,
>
> i have the following program:
>
> import tim
[EMAIL PROTECTED] wrote:
> Call me crazy, but be careful when programming python in different text
> editors and in general, ie cutting and pasting, tabing and spacing.
> Loops can look fine and not work (try moving around test print
> statements for iterators), in this case try re-tabing your inde
>I'm still not sure what was stopping the inner
>loop from working earlier - but removing the redundancy in "j=0" and so
>on seems to have solved it.
Call me crazy, but be careful when programming python in different text
editors and in general, ie cutting and pasting, tabing and spacing.
Loops ca
On 11/05/2006 5:59 PM, Matthew Graham wrote:
> Thanks very much for the advice, have tidied it up and tested and seems
> to be working as needed.
Seems to be working? Consider where you have the expression x^2 + y^2
... I'd like to bet that you mean "x squared" etc, not "x exclusive-or
2" etc.
Thanks very much for the advice, have tidied it up and tested and seems
to be working as needed. I'm still not sure what was stopping the inner
loop from working earlier - but removing the redundancy in "j=0" and so
on seems to have solved it.
Matt
Dennis Lee Bieber wrote:
> If that wor
Oops, I forget to reset the j after the inner loop. Always manage to
work these things out just after asking for help! ;-)
Matthew Graham wrote:
> Hi,
>
> I expect this is very obvious for anyone who knows what they're doing -
> but I don't understand what's the problem with the following code
26 matches
Mail list logo