[Python-ideas] Intermediate Summary: Fast sum() for non-numbers

[David Mertz]

On Mon, Jul 15, 2013 at 10:54 AM, Joshua Landau <joshua at landau.ws> wrote:

> But it *is* addition as far as Python is concerned.
>

Yeah, it is.  I do know that.

What concatenation is NOT is "addition as far as HUMANS are concerned".

Now I'll take your claim as true that 'sum(list_of_lists)' is somehow
intuitive to you.  So I can't say it is counter-intuitive to ALL humans.
But it is counter-intuitive to MANY of us, and for us readers who think of
"sum" as meaning addition in the mathematical sense, code that uses this is
difficult to understand.  At the least it requires a double take and an
extra moment to think through what is meant (i.e. via understanding what
Python does internally).

I will argue that sum()'ing sequences is counter-intuitive for MOST
humans.  It's certainly counter-intuitive to me, and I've written a Python
book, taught Python, and taken graduate mathematics courses (those
experiences may pull in opposite directions though).  I'm also certain it
would be counter-intuitive to programming learners.  I imagine trying to
explain it while teaching Python, and the only thing I could do is tell
them to "ignore what you think sum means, and think about the internals of
Python" ... that's really not a good situation to be in pedagogically.


> *Even if* it was a good idea to restrict "+" to commutative groups
> with constant-time addition (which it is not), the ship has sailed and
> addition in Python means what it does.


I'm not sure it has actually "sailed."  It's very well possible to restrict
sum()'ing lists or tuples in much the same way strings are excluded (even
though strings have an .__add__() method).  If special attention were taken
to *not* work for cases where it shouldn't, we could remove this
counter-intuitive behavior.

That said, even though I think it is *weird* to sum a non-commutuative or
non-associative operation, the runtime checks to figure out whether some
custom type was such would be either outright impossible or needlessly
time-consuming.


> As far as Python is concerned, contancation is a form of addition.
> Maybe not in mathematics, nor Haskell, nor C. But it is in Python, so
> lists in Python are additive groups.
>

No, lists are not additive groups! They do satisfy closure, associativity,
and an identity element of []. However, there's no invertibility on lists.
So even without considering commutativity, lists fail as groups.


> Why? It's not to me. Sure, you need to know the order that it will
> operate, but you need to know that for "reduce" too and no-one says
> using "reduce" in non-commutative ways is insane.
>

Huh?! I have no expectation generically that a sequence must be reduce'd by
a commutative (nor associative) operation.  That's another big way that
reduce is different from sum.

For example, if someone had a function "fastsum()" that took an initial
pass to strike out inverse elements, that might be a reasonable approach.
I'm sure it won't speed up adding ints or floats, but maybe someone has a
complicated "numeric-like" type where "+" is expensive and recognition of
inverse elements is cheap. Possibly this optimization would be a perfectly
sensible approach to a special ?sum() function.  (No, I don't think the
generic sum() should be engineered to do this).  This concept makes no
sense whatsoever thinking about reduce(operator.add, ...) because reduce()
itself doesn't make sense that way.

-- 
Keeping medicines from the bloodstreams of the sick; food
from the bellies of the hungry; books from the hands of the
uneducated; technology from the underdeveloped; and putting
advocates of freedom in prisons.  Intellectual property is
to the 21st century what the slave trade was to the 16th.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20130715/5701d532/attachment.html>