max(), sum(), next()

[David C. Ullrich]

In article 
<719910b1-3776-4bf2-a0b6-236f3167e9e3 at 25g2000prz.googlegroups.com>,
 Mensanator <mensanator at aol.com> wrote:

> 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.

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

-- 
David C. Ullrich