max(), sum(), next()

Ken Starks straton at
Fri Sep 5 11:19:59 CEST 2008

David C. Ullrich wrote:
> In article 
> <719910b1-3776-4bf2-a0b6-236f3167e9e3 at>,
>  Mensanator <mensanator at> wrote:
>> On Sep 3, 2:18 pm, Laszlo Nagy <gand... at> wrote:
>>> bearophileH... at wrote:
>>>> Empty Python lists [] don't know the type of the items it will
>>>> contain, so this sounds strange:
>>>>>>> sum([])
>>>> 0
>>>> Because that [] may be an empty sequence of someobject:
>>> You are right in that sum could be used to sum arbitrary objects.
>>> However, in 99.99% of the cases, you will be summing numerical values.
>>> When adding real numbers, the neutral element is zero. ( X + 0 = X) It
>>> is very logical to return zero for empty sequences.
>> No it isn't. Nothing is not 0, check with MS-Access, for instance:
>> Null + 1 returns Null. Any arithmetic expression involving a
>> Null evaluates to Null. Adding something to an unknown returns
>> an unknown, as it should.
>> It is a logical fallacy to equate unknown with 0.
> Which has nothing to do with the "right" value for an
> empty sum. If they hear about what you said here in
> sci.math they're gonna kick you out - what do you
> imagine the universally accepted value of \sum_{j=1}^0 
> is?
>> For example, the water table elevation in ft above Mean Sea Level
>> is WTE = TopOfCasing - DepthToWater.
>> TopOfCasing is usually known and constant (until resurveyed).
>> But DepthToWater may or may not exist for a given event (well
>> may be covered with fire ants, for example).
>> Now, if you equate Null with 0, then the WTE calculation says
>> the water table elevation is flush with the top of the well,
>> falsely implying that the site is underwater.
>> And, since this particular site is on the Mississippi River,
>> it sometimes IS underwater, but this is NEVER determined by
>> water table elevations, which, due to the CORRECT treatment
>> of Nulls by Access, never returns FALSE calculations.
>>>>> 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.
>>> Same way, if we would have a prod() function, it should return one for
>>> empty sequences because X*1 = X. The neutral element for this operation
>>> is one.
>>> Of course this is not good for summing other types of objects. But how
>>> clumsy would it be to use
>>> sum( L +[0] )
>>> or
>>> if L:
>>> value = sum(L)
>>> else:
>>> value = 0
>>> instead of sum(L).
>>> Once again, this is what sum() is used for in most cases, so this
>>> behavior is the "expected" one.
>>> Another argument to convince you: the sum() function in SQL for empty
>>> row sets returns zero in most relational databases.
>>> But of course it could have been implemented in a different way... I
>>> believe that there have been excessive discussions about this decision,
>>> and the current implementation is very good, if not the best.
>>> Best,
>>> Laszlo

I suppose the following is accepted by statisticians. Here,
for reference, here is the what the 'R' statistic package
says on the subject 9if you type 'help(sum)'

Sum of Vector Elements
sum returns the sum of all the values present in its arguments.

sum(..., na.rm = FALSE)

... numeric or complex or logical vectors.
na.rm logical. Should missing values be removed?

This is a generic function: methods can be defined for it directly or 
via the Summary group generic. For this to work properly, the arguments 
... should be unnamed, and dispatch is on the first argument.

If na.rm is FALSE an NA value in any of the arguments will cause a value 
of NA to be returned, otherwise NA values are ignored.

Logical true values are regarded as one, false values as zero. For 
historical reasons, NULL is accepted and treated as if it were integer(0).

The sum. If all of ... are of type integer or logical, then the sum is 
integer, and in that case the result will be NA (with a warning) if 
integer overflow occurs. Otherwise it is a length-one numeric or complex 
NB: the sum of an empty set is zero, by definition.

Becker, R. A., Chambers, J. M. and Wilks, A. R. (1988) The New S 
Language. Wadsworth & Brooks/Cole.

More information about the Python-list mailing list