Velocity Reviews > sum for sequences?

# sum for sequences?

kj
Guest
Posts: n/a

 03-24-2010

Is there a sequence-oriented equivalent to the sum built-in? E.g.:

seq_sum(((1, 2), (5, 6))) --> (1, 2) + (5, 6) --> (1, 2, 5, 6)

?

(By "sequence" I'm referring primarily to lists and tuples, and
excluding strings, since for these there is ''.join()).

TIA!

~K

Glazner
Guest
Posts: n/a

 03-24-2010
On Mar 24, 5:29*pm, kj <(E-Mail Removed)> wrote:
> Is there a sequence-oriented equivalent to the sum built-in? *E.g.:
>
> * seq_sum(((1, 2), (5, 6))) --> (1, 2) + (5, 6) --> (1, 2, 5, 6)
>
> ?
>
> (By "sequence" I'm referring primarily to lists and tuples, and
> excluding strings, since for these there is ''.join()).
>
> TIA!
>
> ~K

try itertools.chain

Neil Cerutti
Guest
Posts: n/a

 03-24-2010
On 2010-03-24, kj <(E-Mail Removed)> wrote:
>
>
> Is there a sequence-oriented equivalent to the sum built-in? E.g.:
>
> seq_sum(((1, 2), (5, 6))) --> (1, 2) + (5, 6) --> (1, 2, 5, 6)
>
> ?
>
> (By "sequence" I'm referring primarily to lists and tuples, and
> excluding strings, since for these there is ''.join()).

reduce, or functools.reduce in Python 3.1.

>>> functools.reduce(operator.add, ((1, 2), (5, 6)))

(1, 2, 5, 6)

--
Neil Cerutti
"It's not fun to build walls. But it's even less fun to live
without walls in a world full of zombies." --Greedy Goblin

Steve Holden
Guest
Posts: n/a

 03-24-2010
kj wrote:
>
> Is there a sequence-oriented equivalent to the sum built-in? E.g.:
>
> seq_sum(((1, 2), (5, 6))) --> (1, 2) + (5, 6) --> (1, 2, 5, 6)
>
> ?
>
> (By "sequence" I'm referring primarily to lists and tuples, and
> excluding strings, since for these there is ''.join()).
>

Do you mean you want to flatten a list structure? There have been

regards
Steve
--
Steve Holden +1 571 484 6266 +1 800 494 3119
See PyCon Talks from Atlanta 2010 http://pycon.blip.tv/
Holden Web LLC http://www.holdenweb.com/
UPCOMING EVENTS: http://holdenweb.eventbrite.com/

Steven D'Aprano
Guest
Posts: n/a

 03-24-2010
On Wed, 24 Mar 2010 15:29:07 +0000, kj wrote:

> Is there a sequence-oriented equivalent to the sum built-in? E.g.:
>
> seq_sum(((1, 2), (5, 6))) --> (1, 2) + (5, 6) --> (1, 2, 5, 6)
>
> ?

Yes, sum.

>>> a = range(2)
>>> b = range(3)
>>> c = range(4)
>>> sum((a, b, c), [])

[0, 1, 0, 1, 2, 0, 1, 2, 3]

Beware though that sum on lists and tuples will be fairly inefficient if
you have lots of them. You may find that this will be much more efficient:

result = []
for seq in sequences:
result.extend(seq)

--
Steven

Paul Rubin
Guest
Posts: n/a

 03-24-2010
kj <(E-Mail Removed)> writes:
> Is there a sequence-oriented equivalent to the sum built-in? E.g.:
> seq_sum(((1, 2), (5, 6))) --> (1, 2) + (5, 6) --> (1, 2, 5, 6)

use itertools.chain for this. A few people have mentioned that sum will
also work, but I think for that purpose it could have O(n**2)
complexity.

TomF
Guest
Posts: n/a

 03-25-2010
On 2010-03-24 14:07:24 -0700, Steven D'Aprano
<(E-Mail Removed)> said:
> On Wed, 24 Mar 2010 15:29:07 +0000, kj wrote:
>
>> Is there a sequence-oriented equivalent to the sum built-in? E.g.:
>>
>> seq_sum(((1, 2), (5, 6))) --> (1, 2) + (5, 6) --> (1, 2, 5, 6)
>>
>> ?

>
> Yes, sum.
>

You might not want to be so glib. The sum doc sure doesn't sound like
it should work on lists.

Returns the sum of a sequence of numbers (NOT strings) plus the value
of parameter 'start' (which defaults to 0).

-Tom

Steven D'Aprano
Guest
Posts: n/a

 03-25-2010
On Wed, 24 Mar 2010 23:50:23 -0700, TomF wrote:

> On 2010-03-24 14:07:24 -0700, Steven D'Aprano
> <(E-Mail Removed)> said:
>> On Wed, 24 Mar 2010 15:29:07 +0000, kj wrote:
>>
>>> Is there a sequence-oriented equivalent to the sum built-in? E.g.:
>>>
>>> seq_sum(((1, 2), (5, 6))) --> (1, 2) + (5, 6) --> (1, 2, 5, 6)
>>>
>>> ?

>>
>> Yes, sum.
>>

>
> You might not want to be so glib. The sum doc sure doesn't sound like
> it should work on lists.
>
> Returns the sum of a sequence of numbers (NOT strings) plus the
> value of parameter 'start' (which defaults to 0).

What part of that suggested to you that sum might not be polymorphic?
Sure, it says numbers (which should be changed, in my opinion), but it
doesn't specify what sort of numbers -- ints, floats, or custom types
that have an __add__ method. It also singles out strings as excluded. Why
would you need to explicitly exclude strings, since they're not numbers,
if sum *only* works with numbers?

E.g. help(math.sin) could have said this, but doesn't:

Return the sine of x (NOT a dictionary)

It doesn't need to, because dicts aren't exceptional: sin doesn't work on
anything *but* numbers. There's no __sin__ method to call on arbitrary
types.

The fact that sum does single out strings is a clear sign that strings
are treated as exceptional and suggests strongly that summing arbitrary
types should work. I'm not saying that help(sum) explicitly states that
it works with lists (it clearly doesn't), but it does suggest the
possibility and makes the experiment worth trying.

I'll also note that the Fine Manual makes it even more clear that sum is
polymorphic:

http://docs.python.org/library/functions.html#sum

--
Steven

Neil Cerutti
Guest
Posts: n/a

 03-25-2010
On 2010-03-25, Steven D'Aprano <(E-Mail Removed)> wrote:
>> You might not want to be so glib. The sum doc sure doesn't
>> sound like it should work on lists.
>>
>> Returns the sum of a sequence of numbers (NOT strings) plus the
>> value of parameter 'start' (which defaults to 0).

>
> What part of that suggested to you that sum might not be polymorphic?
> Sure, it says numbers (which should be changed, in my opinion), but it
> doesn't specify what sort of numbers -- ints, floats, or custom types
> that have an __add__ method.

WTF.

--
Neil Cerutti
"It's not fun to build walls. But it's even less fun to live
without walls in a world full of zombies." --Greedy Goblin

Stefan Behnel
Guest
Posts: n/a

 03-25-2010
Neil Cerutti, 25.03.2010 13:37:
> On 2010-03-25, Steven D'Aprano wrote:
>>> You might not want to be so glib. The sum doc sure doesn't
>>> sound like it should work on lists.
>>>
>>> Returns the sum of a sequence of numbers (NOT strings) plus the
>>> value of parameter 'start' (which defaults to 0).

>>
>> What part of that suggested to you that sum might not be polymorphic?
>> Sure, it says numbers (which should be changed, in my opinion), but it
>> doesn't specify what sort of numbers -- ints, floats, or custom types
>> that have an __add__ method.

>
> WTF.

Warning: truth found!

Stefan