max(), sum(), next()

Mensanator mensanator at aol.com
Thu Sep 4 07:57:19 CEST 2008


On Sep 4, 12:20�am, Mensanator <mensana... at aol.com> wrote:
> 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.

I just checked and I mis-remembered how this works.
The option is for blanks to plot as holes or 0 or
be interpolated. 0 always plots as 0. The inconsistency
is that blanks are still evaluated as 0 in formulae
and macros.

>
> > 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- Hide quoted text -
>
> - Show quoted text -




More information about the Python-list mailing list