S
Steven D'Aprano
chain is only for finite sequences. For arbitrary sequences, use
chain.from_iterable.
Correction noted. Obviously I'm not Dutch.
chain is only for finite sequences. For arbitrary sequences, use
chain.from_iterable.
You're exceptionally good at (probably deliberately) mis-interpreting
what people write.
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.
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
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????
You don't define symmetry. You don't even give a sensible example of
symmetry. Consequently I reject your argument that because sum is the
obvious way to sum a lot of integers, "symmetry" implies that it should
be the obvious way to concatenate a lot of lists.
You are correct that building intermediate lists isn't *compulsory*,
there are alternatives, but the alternatives themselves have costs.
Complexity itself is a cost. sum currently has nice simple semantics,
which means you can reason about it: sum(sequence, start) is the same as
total = start
for item in sequence:
total = total + start
return total
[1]>>> start = []
>>> x = sum([], start)
>>> x.append(1)
>>> start
You don't have to care what the items in sequence are, you don't have to
make assumptions about what methods sequence and start have (beyond
supporting iteration and addition).
Adding special cases to sum means it
becomes more complex and harder to reason about. If you pass some other
sequence type in the middle of a bunch of lists, what will happen? Will
sum suddenly break, or perhaps continue to work but inefficiently?
[1, 2, 'f', 'o', 'o']>>> list = [1, 2]
>>> list += "foo"
>>> list
[1, 2, 'f', 'o', 'o']>>> lst = [1,2]
>>> lst.extend('foo')
>>> lst
....start = []
bogus_example = [[1, 2], None, [3]]
for item in bogus_example: start += item
You still need to ask these questions with existing sum, but it is
comparatively easy to answer them: you only need to consider how the
alternative behaves when added to a list. You don't have to think about
the technicalities of the sum algorithm itself -- sometimes it calls +,
sometimes extend, sometimes +=, sometimes something else
... which of the
various different optimized branches will I fall into this time? Who
knows? sum already has two branches. In my opinion, three branches is one
too many.
"Aggregating" lists? Not summing them? I think you've just undercut your
argument that sum is the "obvious" way of concatenating lists.
In natural language, we don't talk about "summing" lists, we talk about
joining, concatenating or aggregating them. You have just done it
yourself, and made my point for me.
And this very thread started because
somebody wanted to know what the equivalent to sum for sequences.
If sum was the obvious way to concatenate sequences, this thread wouldn't
even exist.
It's about a lack of surprises. Which, 99% of the time, Python excels
at. This is why many of us program in Python. This is why some of us
who would never use sum() on lists, EVEN IF IT WERE FIXED TO NOT BE SO
OBNOXIOUSLY SLOW, advocate that it, in fact, be fixed to not be so
obnoxiously slow.
On Mar 29, 4:19Â pm, Steven D'Aprano <st...@REMOVE-THIS-
cybersource.com.au> wrote: [...]Let's go through them...Python is under no compulsion to make "the obvious way" obvious to
anyone except Guido. It's a bonus if it happens to be obvious to
newbies, not a requirement.
And besides, what is "it" you're talking about?
* Adding integers, decimals or fractions, or floats with a low
 requirement for precision and accuracy? Use sum.
* Adding floats with a high requirement for precision and accuracy?
 Use math.fsum.
* Concatenating strings? Use ''.join.
* Joining lists? Use [].extend.
* Iterating over an arbitrary sequence of arbitrary sequences?
 Use itertools.chain.
That's five different "its", and five obvious ways to do them.
Traceback (most recent call last):fsum([1.234534665989, 2.987, 3])
File "<stdin>", line 1, in <module>
NameError: name 'fsum' is not defined
* Concatenating strings? Use ''.join.
Common pitfall:
Traceback (most recent call last):['abc', 'def', 'ghi'].join()
File "<stdin>", line 1, in <module>
AttributeError: 'list' object has no attribute 'join'
* Joining lists? Use [].extend.
Obvious, yes. Convenient? Not really.
... start.extend(list)start = []
for list in [[1, 2], [3, 4]]:
...[1, 2, 3, 4]
* Iterating over an arbitrary sequence of arbitrary sequences?
Use itertools.chain.group1 = ['al', 'bob']
group2 = ['cal']
groups = [group1, group2]
Obvious if you are Dutch...
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
NameError: name 'itertools' is not defined
Sum is builtin, but you have to import fsum from math and chain from
itertools.
Join is actually a method on strings, not sequences.
Just commit all that to memory, and enjoy the productivity of using a
high level language!
Steven D'Aprano said:"Obvious" doesn't mean you don't have to learn the tools you use....
Geez you guys, get a room ;-). You're all good programmers with too
much experience for this arguing over stuff this silly.
Yeah, it can happen to all of us. I've certainly been "that guy" too.Steven said:Yes Mum
You're right of course. I spend too much time being this guy:
http://xkcd.com/386/
and not enough this one:
http://xkcd.com/167/
Yeah, it can happen to all of us. I've certainly been "that guy" too.Steven said:Yes Mum
You're right of course. I spend too much time being this guy:
http://xkcd.com/386/
and not enough this one:
http://xkcd.com/167/
Patrick said: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:
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
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
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.
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.)
Want to reply to this thread or ask your own question?
You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.