max(), sum(), next()

[James Mills]

Can we stop this thread now? :)

I think we've all seen what the intended
behavior of sum(), max() and other
similar functions.

cheers
James

On Mon, Sep 8, 2008 at 3:30 AM, Mensanator <mensanator at aol.com> wrote:
> On Sep 6, 11:05�pm, Steven D'Aprano <st... at REMOVE-THIS-
> cybersource.com.au> wrote:
>> On Sat, 06 Sep 2008 11:22:07 -0700, Mensanator wrote:
>>
>> [...]
>>
>> >> They could have decided that sum must take at least two arguments,
>> >> because addition requires two arguments and it's meaningless to talk
>> >> about adding a single number without talking about adding it to
>> >> something else. But they didn't.
>>
>> > Ok. But the problem is they DID in SQL: x + Null = Null.
>>
>> Sheesh. That's not a problem, because Python is not trying to be a
>> dialect of SQL.
>
> And yet, they added a Sqlite3 module.
>
>>
>> If you want a NULL object, then there are recipes on the web that will
>> give you one. Then all you need to do is call sum(alist or [NULL]) and it
>> will give you the behaviour you want.
>
> Actualy, I already get the behaviour I want. sum([1,None])
> throws an exception. I don't see why sum([]) doesn't throw
> an exception also (I understand that behaviour is by design,
> I'm merely pointing out that the design doesn't cover every
> situation).
>
>>
>> [...]
>>
>> > Here's a real world example (no ivory tower stuff):
>>
>> > An oil refinery client has just excavated a big pile of dirt to lay a
>> > new pipeline.
>> [snip details]
>> > Can't I just use a sum of 0 to tell me when data is missing? No, because
>> > in some cases the reporting limit of undetected compounds is set to 0.
>>
>> You can't use a sum of 0 to indicate when data is missing, full stop.
>
> Exactly. That's why I would prefer sum([]) to raise an
> exception instead of giving a false positive.
>
>> The
>> data may require 15 tests when only 3 have actually been done:
>>
>> sum([1.2e-7, 9.34e-6, 2.06e-8])
>
> Biggest problem here is that it is often unknown just
> how many records you're supposed to get from the query,
> so we can't tell that a count of 3 is supposed to be 15.
>
>>
>> Missing data and a non-zero sum. How should sum() deal with that?
>
> That's a seperate issue and I'm not saying it should as
> long as the list contains actual numbers to sum.
> sum([1.2e-7, 9.34e-6, 2.06e-8, None]) will raise an
> exception, as it should. But what types are contained
> in []?
>
>>
>> The answer is that sum() can't deal with that. You can't expect sum() to
>> read your mind, know that there should be 15 items instead of 3, and
>> raise an error. So why do you expect sum() to read your mind and
>> magically know that zero items is an error, especially when for many
>> applications it is NOT an error?
>
> For the simple reason it doesn't have to read your mind,
> a mechanism has already been built into the function: start
> value. For those situations where an empty list is desired
> to sum to 0, you could use sum(alist,0) and use sum(alist) for
> those cases where summing an empty list is meaningless.
> Shouldn't you have to explicitly tell sum() how deal with
> situations like empty lists rather than have it implicitly
> assume a starting value of 0 when you didn't ask for it?
>
>>
>> The behaviour you want for this specific application is unwanted,
>> unnecessary and even undesirable for many other applications. The
>> solution is for *you* to write application-specific code to do what your
>> application needs, instead of relying on a general purpose function
>> magically knowing what you want.
>
> Does division magically know what you want? No, it raises an
> exception when you do something like divide by 0. Isn't it
> Pythonic to not write a litany of tests to cover every
> possible case, but instead use try:except?
>
> But try:except only works if the errors are recognized.
> And sum() says that summing an empty list is NEVER an error
> under ANY circumstance. That may be true in MOST cases, but
> it certainly isn't true in ALL cases.
>
>>
>> --
>> Steven
>
> --
> http://mail.python.org/mailman/listinfo/python-list



-- 
--
-- "Problems are solved by method"