On Wed, 03 Sep 2008 22:20:43 -0700, Mensanator 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.
It is to laugh.
> Microsoft knows that this is a bug
Says you.
> 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
"Graphing data" is not sum(). I don't expect graphing data to result in
the same result as sum(), why would I expect them to interpret input the
same way?
> +------+ +--+------+------+-----+
Why should the graphing application ignore blanks ("missing data"), but
sum() treat missing data as an error? That makes no sense at all.
> and not evaluated as 0
>
> 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'm not aware of any spreadsheet that treats empty cells as zero for the
purpose of graphing, and I find your claim that Excel can't draw graphs
with zero in them implausible, but I don't have a copy of Excel to test
it.
>> 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.
Neither databases nor surface contours are sum(). What possible relevance
are they to the question of what sum() should do?
Do you perhaps imagine that there is only "ONE POSSIBLE CORRECT WAY" to
deal with missing data, and every function and program must deal with it
the same way?
> Contour programs REQUIRE that blanks are null, not 0
Lucky for them that null is not 0 then.
> 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.
No no no, you messed that sentence up. What you *really* meant was:
"Access' treatment of Nulls is inconsistent with Excel's treatment of
blank cells and therefore wrong, anyway you slice it."
No of course not. That would be stupid, just as stupid as your sentence.
Excel is not Access. They do different things. Why should they
necessarily interpret data the same way?
> 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.
Who decides what it is supposed to do if not the author? You, in your
ivory tower who doesn't care a fig for what people want the software to
do?
Bug report: "Software does what users want it to do."
Fix: "Make the software do something that users don't want."
Great.
>> 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.
You've given a good example yourself: the Kriging algorithm needs a Null
value which is not zero. There is no mathematical "null" which is
distinct from zero, so there's an excellent violation of mathematical
purity right there.
If I am given the job of adding up the number of widgets inside a box,
and the box is empty, I answer that there are 0 widgets inside it. If I
were to follow your advice and declare that "An error occurred, can't
determine the number of widgets inside an empty box!" people would treat
me as an idiot, and rightly so.
> 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.
Well Excel, Python agree that the sum of an empty list is 0. What do
Access and Mathematica do?
>> 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].
The way to distinguish lists is NOT to add them up and compare the sums:
>>> sum([4, -4]) == sum([0]) == sum([1, 2, 3, -6]) == sum([-1, 2, -1])
True
The correct way is by comparing the lists themselves:
>>> [] == [4, -4]
False
>> 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)?
I don't want [] == 0. That's foolish. I want the sum of an empty list to
be 0, which is a very different thing.
And I don't need to say sum([],0) because the default value for the
second argument is 0.
> Why shouldn't nothing added to nothing return nothing? Having it
> evaluate to 0 is wrong 99.9% of the time.
It is to laugh.
What's the difference between having 0 widgets in a box and having an
empty box with, er, no widgets in it?
--
Steven
--
http://mail.python.org/mailman/listinfo/python-list
