max(), sum(), next()

[Mensanator]

On Sep 4, 12:31 pm, Thomas Bellman <bell... at lysator.liu.se> wrote:
> Mensanator <mensana... at aol.com> wrote:
> > Ok, but I don't understand why an empty list is a valid sum
> > whereas a list containing None is not.
>
> You can't conclude the behaviour of the one from the behaviour
> of the other, because the two situations have nothing at all in
> common.

I wouldn't say they have nothing in common. After all, neither []
nor [None,None] contain any integers, yet summing the first gives
us an integer result whereas summing the second does not. Yes, for
different unrelated reasons, but sometimes reasons aren't as important
as results.

>
> >> As it happens, the SQL sum() function (at least in MySQL; I don't
> >> have any other database easily available, nor any SQL standard to
> >> read) does return NULL for a sum over the empty sequence, so you
> >> could argue that that would be the correct behaviour for the
> >> Python sum() function as well, but you can't argue that because a
> >> sum *involving* a NULL value returns NULL.
> > I'm not following that. Are you saying a query that returns no
> > records doesn't have a specific field containg a Null so there
> > are no Nulls to poison the sum? ...tap...tap...tap. Ok, I can see
> > that,
>
> Exactly.
>
> > but you don't get 0 either.
>
> That's because the SQL sum() has a special case for "no rows
> returned".  A *different* special case than the one that taint's
> the sum when encountering a NULL.  It does the equivalent of
>
>     if len(rows_returned) == 0:
>         # Special case for no rows returned
>         return NULL
>     total = 0
>     for row in rows_returned:
>         value = row[column]
>         if value is NULL:
>             # Special case for encountering a NULL value
>             return NULL
>         total += value
>     return total
>
> Two different special cases for the two different situations.  If
> you were to remove the special case for no rows returned, you
> would get zero when the SELECT statement finds no rows, but the
> sum would still be tainted when a NULL value is encountered..
>
> The definition of sum in mathematics *does* do away with that
> special case.  The sum of zero terms is zero.  And the Python
> sum() function follows the mathematics definition in this
> respect, not the SQL definition.

Too bad. I brought this up because I use Python a lot with
database work and rarely for proving theorms in ZFC.

Guess I have to work around it. Just one more 'gotcha' to
keep track of.

>
> You can argue that Python sum() should have special cased the
> empty sequence.  

I did.

> It's not an illogical stance to take.  

I didn't think so.

> It's just
> a totally different issue from encountering a non-numeric element
> in the sequence.  

Ok, I was paying more attention to the outcome.

> In some cases it might actually make sense to
> treat the empty sequence as an error, but just ignore non-numeric
> elements (i.e, treat them as if they were zero).  

Ouch. Sounds like Excel and we don't want to go there.

> And in some
> cases both should be an error, and in some neither should be an
> error.
>
> --
> Thomas Bellman,   Lysator Computer Club,   Linköping University,  Sweden
> "You are in a twisty little passage of       !  bellman @ lysator.liu.se
>  standards, all conflicting."                !  Make Love -- Nicht Wahr!