max(), sum(), next()

[Mensanator]

On Sep 3, 8:30�pm, Steven D'Aprano <st... at REMOVE-THIS-
cybersource.com.au> wrote:
> On Wed, 03 Sep 2008 16:20:39 -0700, Mensanator wrote:
> >>>> sum([])
> > 0
>
> > is a bug, just as it's a bug in Excel to evaluate blank cells as 0. It
> > should return None or throw an exception like sum([None,1]) does.
>
> You're wrong, because 99.9% of the time when users leave a blank cell in
> Excel, they want it to be treated as zero.

Then 99.9% of users want the wrong thing. Microsoft knows that
this is a bug but refuses to fix it to prevent breaking legacy
documents (probably dating back to VisiCalc). When graphimg data,
a missing value should be interpreted as a hole in the graph

+------+             +--+------+------+-----+


and not evaluated as 0

+------+             +--+------+------+-----+
        \           /
         \         /
          \       /
           \     /
            \   /
             \+/

(depending on the context of the graph, of course).

And Microsoft provides a workaround for graphs to make 0's
appear as holes. Of course, this will cause legitimate 0
values to disappear, so the workaround is inconsistent.


> Spreadsheet sum() is not the
> same as mathematician's sum, which doesn't have a concept of "blank
> cells". (But if it did, it would treat them as zero, since that's the
> only useful thing and mathematicians are just as much pragmatists as
> spreadsheet users.) The Excel code does the right thing, and your "pure"
> solution would do the unwanted and unexpected thing and is therefore
> buggy.

Apparently, you don't use databases or make surface contours.
Contour programs REQUIRE that blanks are null, not 0, so that
the Kriging algorithm interpolates around the holes rather than
return false calculations. Excel's treatment of blank cells is
inconsistent with Access' treatment of Nulls and therefore wrong,
anyway you slice it. Math isn't a democracy, what most people want
is irrelevant.

I don't pull these things out of my ass, it's real world stuff
I observe when I help CAD operators and such debug problems.

Maybe you want to say a bug is when it doesn't do what the
author intended, but I say if what the intention was is wrong,
then a perfect implentation is still a bug because it doesn't
do what it's supposed to do.

>
> Bugs are defined by "does the code do what the user wants it to do?", not
> "is it mathematically pure?".

ReallY? So you think math IS a democracy? There is no reason to
violate
mathematical purity. If I don't get EXACTLY the same answer from
Excel,
Access, Mathematica and Python, then SOMEBODY is wrong. It would be a
shame if that somebody was Python.

> The current behaviour of sum([]) does the
> right thing for the 99% of the time when users expect an integer.

Why shouldn't the users expect an exception? Isn't that why we have
try:except? Maybr 99% of users expect sum([])==0, but _I_ expect to
be able to distinguish an empty list from [4,-4].

> And the
> rest of the time, they have to specify a starting value for the sum
> anyway, and so sum([], initial_value) does the right thing *always*.

So if you really want [] to be 0, why not say sum([],0)?

Why shouldn't nothing added to nothing return nothing?
Having it evaluate to 0 is wrong 99.9% of the time.

>
> The only time it does the wrong thing[1] is when you forget to pass an
> initial value but expect a non-numeric result. And that's the
> programmer's error, not a function bug.
>
> [1] I believe it also does the wrong thing by refusing to sum strings,
> but that's another story.
>
> --
> Steven