On Sep 4, 12:20�am, Mensanator <[EMAIL PROTECTED]> wrote: > On Sep 3, 8:30 pm, Steven D'Aprano <[EMAIL PROTECTED] > > 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 - -- http://mail.python.org/mailman/listinfo/python-list