max(), sum(), next()
mensanator at aol.com
Thu Sep 4 01:20:39 CEST 2008
On Sep 3, 2:18 pm, Laszlo Nagy <gand... at shopzeus.com> wrote:
> bearophileH... at lycos.com 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.
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.
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])
> 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 + )
> if L:
> value = sum(L)
> 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.
More information about the Python-list