<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 01/30/2014 05:27 PM, Steven D'Aprano
wrote:<br>
</div>
<blockquote cite="mid:20140131012705.GF3799@ando" type="cite">
<pre wrap="">I'm hesitant to require two passes over the data in _sum. Some
higher-order statistics like variance are currently implemented using
two passes, but ultimately I've like to support single-pass algorithms
that can operate on large but finite iterators.
But I will consider it as an option.
I'm also hesitant to make the promise that _sum will be
order-independent. Addition in Python isn't: [...]</pre>
</blockquote>
<br>
I concede that this is mostly outside my expertise, and the
statistics module and the PEP were your doing. So you're the expert
here and I will defer to you.<br>
<br>
But. My dim understanding of the *whole point* of the new
statistics module was that it valued correctness over raw
performance. I assumed sorting values from small to large** before
summing was *exactly* the sort of thing it was written to do. If
all we wanted were Python's existing semantics, why bother writing
statistics._sum() in the first place? Just use sum().<br>
<br>
On the other hand, I had missed the fact that this was an
internal-only method. If changing _statistics._sum so it reordered
the iterable to preserve correctness wouldn't change the behavior of
any supported external APIs, then obviously there's no need, and I'd
prefer to leave it alone for 3.4. If you decided to change it for
3.5 and people were relying on its old behavior, that would be on
them. (Though a comment saying "I might change this later" would be
welcome... if true.)<br>
<br>
<br>
<blockquote cite="mid:20140131012705.GF3799@ando" type="cite">
<pre wrap="">If you're worried about people coming to rely on this, and thus running
into trouble in the future if Counters get treated specially for (say)
weighted data, then I'd accept a warning in the docs, or even a runtime
warning. But not an exception.
</pre>
</blockquote>
<br>
The statistics module isn't marked as provisional. So the semantics
that ship with 3.4 are going to be set in stone. Changing them
later simply won't be an option--that will break code. If you want
to treat Counter objects differently in the future than you do now,
then I agree with Wolfgang: the best course of action would be to
add an exception now. But again I'll defer to your judgment about
what's best for your module.<br>
<br>
<br>
<i>/arry</i><br>
<br>
** Or high-precision to low-precision. You know what I mean, the
classic "if you add large numbers first you throw away precision and
can wind up with a different result" thing.<br>
</body>
</html>