Velocity Reviews > sum for sequences?

# sum for sequences?

Mel
Guest
Posts: n/a

 03-30-2010
Patrick Maupin wrote:

> Because sum() is the obvious way to sum floats; now the existence of
> math.fsum() means there are TWO obvious ways to sum floats. Is that
> really that hard to understand? How can you misconstrue this so badly
> that you write something that can be (easily) interpreted to mean that
> you think that I think that once math.fsum() exists, sum() doesn't
> even exist any more????

floats are nasty -- as evidence the recent thread on comparing floats for
equality. People use floats when they have to. fsum exists because of
this:

mwilson@tecumseth:~\$ python
Python 2.6.2 (release26-maint, Apr 19 2009, 01:56:41)
[GCC 4.3.3] on linux2
>>> from math import fsum
>>> a=(1.0e200, 156.0, -1.0e200)
>>> sum(a)

0.0
>>> fsum(a)

156.0

You could generalize sum, but after that, there's a case that even fsum
can't handle:

>>> ni=1.0e200+1.0j
>>> nj=1.0+1.0e200j
>>> ai=(ni, nj, 156.0+651.0j, -ni, -nj)
>>> sum(ai)

(-1+0j)
>>> fsum(ai)

Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: can't convert complex to float; use abs(z)
>>>

Mel.

Patrick Maupin
Guest
Posts: n/a

 03-30-2010
On Mar 30, 8:53*am, Mel <(E-Mail Removed)> wrote:
> floats are nasty -- as evidence the recent thread on comparing floats for
> equality. *People use floats when they have to. *fsum exists because of
> this:

....

I understand there are technical reasons for why math.fsum() exists.
I still think that whatever math.fsum() does should probably be a part
of sum().

Regards,
Pat

Albert van der Horst
Guest
Posts: n/a

 04-06-2010
In article <(E-Mail Removed)>,
Patrick Maupin <(E-Mail Removed)> wrote:
>On Mar 29, 10:29=A0pm, Steven D'Aprano
><(E-Mail Removed)> wrote:
>> On Mon, 29 Mar 2010 19:24:42 -0700, Patrick Maupin wrote:
>> > On Mar 29, 6:19=A0pm, Steven D'Aprano <st...@REMOVE-THIS-
>> > cybersource.com.au> wrote:
>> >> How does the existence of math.fsum contradict the existence of sum?

>>
>> > You're exceptionally good at (probably deliberately) mis-interpreting
>> > what people write.

>>
>> I cannot read your mind, I can only interpret the words you choose to
>> write. You said
>>
>> [quote]
>> See, I think the very existence of math.fsum() already violates "there
>> should be one obvious way to do it."
>> [end quote]
>>
>> If sum satisfies the existence of one obvious way, how does math.fsum
>> violate it? sum exists, and is obvious, regardless of whatever other
>> solutions exist as well.

>
>Because sum() is the obvious way to sum floats; now the existence of
>math.fsum() means there are TWO obvious ways to sum floats. Is that
>really that hard to understand? How can you misconstrue this so badly
>that you write something that can be (easily) interpreted to mean that
>you think that I think that once math.fsum() exists, sum() doesn't
>even exist any more????

To a mathematician sum(set) suggest that the order of summation
doesn't matter. (So I wouldn't use sum for concatenating lists.)
Harshly, sum() should be used only for operator + both associative and
commutative.

Now for floating point numbers the order of summation is crucial,
not commutative (a+b)+c <> a+(b+c).
So the obvious thing for someone versed in numerical computing
do is looking whether sum() gives any guarantees for order and
whether there may be a special sum() for floating point.
(This is not very realistic, because such a person would have
skimmed the math library a long time ago, but anyway.)

Met vriendelijke groeten,
Albert van der Horst

--
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- like all pyramid schemes -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

--
--
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

Patrick Maupin
Guest
Posts: n/a

 04-06-2010
On Apr 6, 8:39*am, Albert van der Horst <(E-Mail Removed)4all.nl>
wrote:

> To a mathematician sum(set) suggest that the order of summation
> doesn't matter. (So I wouldn't use sum for concatenating lists.)
> Harshly, sum() should be used only for operator + both associative and
> commutative.

That's all well and good, but not every Python user is a
mathematician. As long as Python doesn't surprise mathematicians in a
way that is too negative (I can see the complaint now: "Hey! sum()
kept my lists ordered! I was expecting some randomization!") what is
wrong with it also not surprising the average user in a way that is
too negative?

Regards,
Pat

Neil Cerutti
Guest
Posts: n/a

 04-06-2010
On 2010-04-06, Albert van der Horst <(E-Mail Removed)4all.nl> wrote:
> To a mathematician sum(set) suggest that the order of summation
> doesn't matter. (So I wouldn't use sum for concatenating
> lists.) Harshly, sum() should be used only for operator + both
> associative and commutative.
>
> Now for floating point numbers the order of summation is
> crucial, not commutative (a+b)+c <> a+(b+c). So the obvious
> thing for someone versed in numerical computing do is looking
> whether sum() gives any guarantees for order and whether there
> may be a special sum() for floating point. (This is not very
> realistic, because such a person would have skimmed the math
> library a long time ago, but anyway.)

I'm convinced by this argument. I just have to be a mathematician
and a computer scientist skilled in numerical computing. No
problem! Just a *few more years* of education and I'll be ready
for summing things in Python.

--
Neil Cerutti