On Sep 4, 11:13 am, "David C. Ullrich" <[EMAIL PROTECTED]> wrote:
> In article
> <[EMAIL PROTECTED]>,
>
>
>
>
>
> Mensanator <[EMAIL PROTECTED]> wrote:
> > On Sep 3, 2:18 pm, Laszlo Nagy <[EMAIL PROTECTED]> wrote:
> > > [EMAIL PROTECTED] 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.
I'm less concerned about the "right" value than a consistent
value. I'm fairly certain you can't get 0 from a query that
returns no records, so I don't like seeing empty being
treated as 0, even if it means that in set theory because
databases aren't sets.
> If they hear about what you said here in
> sci.math they're gonna kick you out
They usually don't kick me out, just kick me.
> - what do you
> imagine the universally accepted value of \sum_{j=1}^0
> is?
I can't follow your banter, so I'm not sure what it should be.
>
>
>
>
>
> > 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
--
http://mail.python.org/mailman/listinfo/python-list
