On Sep 13, 9:27 pm, Hrvoje Niksic <[EMAIL PROTECTED]> wrote:
> Note that, despite appearances, it's not as built-in as one might
> wish. sum(seq) is still completely generic and works on all
> number-like objects (in fact on all objects that define an __add__
> operation except strings, which are
Terry Reedy <[EMAIL PROTECTED]> writes:
>> Of course, sum() is even faster than reduce:
>>
> Timer('sum(xrange(1))').repeat(number=1)
>> [9.814924955368042, 8.7169640064239502, 9.5062401294708252]
>
> 'Of course', because the irreducible difference between
> reduce(add.seq) and sum(seq
Steven D'Aprano wrote:
If you want to see reduce really shine, time it with a C-based function
rather than one written in pure Python:
Timer('reduce(add, xrange(1))',
... 'from operator import add').repeat(number=1)
[19.724750995635986, 19.410486936569214, 19.614511013031006]
Timer
On Sat, 13 Sep 2008 01:06:22 -0700, cnb wrote:
> This must be because of implementation right? Shouldn't reduce be faster
> since it iterates once over the list? doesnt sum first construct the
> list then sum it?
What makes you think that?
Given the speed of sum(), it sure doesn't look like it's
On Sep 13, 10:06 am, cnb <[EMAIL PROTECTED]> wrote:
> This must be because of implementation right? Shouldn't reduce be
> faster since it iterates once over the list?
> doesnt sum first construct the list then sum it?
No, sum also iterates the sequence just once and doesn't create a
list. It is pr
> doesnt sum first construct the list then sum it?
> def com(lst):
> return sum(x for x in lst)
You construct a generator over an existing list in your code.
Try sum([x for x in lst]) to see the effect of additional list
construction. And while you're at it, try the simple sum(lst).
Cheers,
On Sat, 13 Sep 2008 01:06:22 -0700, cnb wrote:
> This must be because of implementation right? Shouldn't reduce be faster
> since it iterates once over the list? doesnt sum first construct the
> list then sum it?
No it doesn't. Why should it?
> also, using range instead of xrange doesnt seem to
This must be because of implementation right? Shouldn't reduce be
faster since it iterates once over the list?
doesnt sum first construct the list then sum it?
---
>>> RESTART
>>>
reduce with named function: 37
