Larry Hastings added the comment:
Mr. D'Aprano emailed me about getting this in for alpha 4. Since nobody else
stepped up, I volunteered to check it in for him. There were some minor ReST
errors in statistics.rst but I fixed 'em.
--
nosy: +larry
Guido van Rossum added the comment:
Thanks Larry!
On Sat, Oct 19, 2013 at 11:32 AM, Larry Hastings rep...@bugs.python.orgwrote:
Larry Hastings added the comment:
Mr. D'Aprano emailed me about getting this in for alpha 4. Since nobody
else stepped up, I volunteered to check it in for him.
Roundup Robot added the comment:
New changeset 685e044bed5e by Larry Hastings in branch 'default':
Issue #18606: Add the new statistics module (PEP 450). Contributed
http://hg.python.org/cpython/rev/685e044bed5e
--
nosy: +python-dev
___
Python
Larry Hastings added the comment:
Checked in. Thanks, Mr. D'Aprano!
--
resolution: - fixed
stage: - committed/rejected
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18606
Georg Brandl added the comment:
I'm sorry if I stepped on your toes, but I didn't ignore your patch. If I've
failed to follow the right procedure, it is due to inexperience, not malice.
You yourself suggested it was only a temporary version just good enough to
get the module committed,
Steven D'Aprano added the comment:
Here is the updated version which I hope is not too late for alpha 4. Main
changes:
* sum is now private
* docstrings have been simplified and shrunk somewhat
* I have a draft .rst file, however I'm having trouble getting Sphinx working
on my system and I
Georg Brandl added the comment:
The rst file is missing from your patch.
I already posted a patch with statistics.rst five days ago. I have no idea why
you ignored it.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18606
Steven D'Aprano added the comment:
Georg Brandl wrote:
The rst file is missing from your patch.
Oops! Sorry about that. Fixed now.
I already posted a patch with statistics.rst five days ago.
I have no idea why you ignored it.
I'm sorry if I stepped on your toes, but I didn't ignore your
Nick Coghlan added the comment:
+0 for starting with _sum as private and +1 for getting this initial
version checked in for alpha 4.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18606
Nick Coghlan added the comment:
Are the ReST docs the only missing piece here? It would be nice to have this
included in alpha 4 next weekend (although the real deadline is beta 1 on
November 24).
--
nosy: +ncoghlan
___
Python tracker
Georg Brandl added the comment:
In the attached patch I took the docstrings, put them in statistics.rst and
reformatted/marked-up them according to our guidelines. This should at least
be good enough to make this committable.
I also modified statistics.py very slightly; I removed trailing
Steven D'Aprano added the comment:
On Sun, Oct 13, 2013 at 09:21:13AM +, Nick Coghlan wrote:
Nick Coghlan added the comment:
Are the ReST docs the only missing piece here?
As far as I know, the only blocker is that the ReST docs are missing.
Also Guido would like to see the
Steven D'Aprano added the comment:
Oscar Benjamin has just made a proposal to me off-list that has *almost*
convinced me to make statistics.sum a private implementation detail, at
least for the 3.4 release. I won't go into detail about Oscar's
proposal, but it has caused me to rethink all the
Tim Peters added the comment:
Do what's best for the future of the module. A PEP is more of a starting point
than a constraint, especially for implementation details. And making a private
thing public later is one ginormous whale of a lot easier than trying to remove
a public thing later.
Raymond Hettinger added the comment:
I think this should get checked in so that people can start interacting with
it. The docstrings and whatnot can get tweaked later.
--
nosy: +rhettinger
___
Python tracker rep...@bugs.python.org
Changes by Stefan Krah stefan-use...@bytereef.org:
--
nosy: +skrah
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18606
___
___
Python-bugs-list
Guido van Rossum added the comment:
Here's a combined patch. Hopefully it will code review properly.
--
nosy: +gvanrossum
Added file: http://bugs.python.org/file31680/statistics_combined.patch
___
Python tracker rep...@bugs.python.org
Guido van Rossum added the comment:
Nice docstrings, but those aren't automatically included in the Doc tree.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18606
___
janzert added the comment:
Seems that the discussion is now down to implementation issues and the PEP is
at the point of needing to ask python-dev for a PEP dictator?
--
nosy: +janzert
___
Python tracker rep...@bugs.python.org
Oscar Benjamin added the comment:
On Aug 28, 2013 1:43 AM, janzert rep...@bugs.python.org wrote:
Seems that the discussion is now down to implementation issues and the
PEP is at the point of needing to ask python-dev for a PEP dictator?
I would say so. AFAICT Steven has addressed all of the
Steven D'Aprano added the comment:
I have changed the algorithm for statistics.sum to use long integer summation
of numerator/denominator pairs.
This removes the concerns Mark raised about the float addition requiring
correct rounding. Unless I've missed something, this now means that
Oscar Benjamin added the comment:
On 22 August 2013 03:43, Steven D'Aprano rep...@bugs.python.org wrote:
If Oscar is willing, I'd like to discuss some of his ideas off-list, but that
may take some time.
I am willing and it will take time.
I've started reading the paper that Raymond
Steven D'Aprano added the comment:
On 20/08/13 22:43, Mark Dickinson wrote:
I agree with Oscar about sum for decimal.Decimal. The *ideal* sum for
Decimal instances would return the correctly rounded result (i.e., the exact
result, rounded to the current context just once using the current
Mark Dickinson added the comment:
I agree with Oscar about sum for decimal.Decimal. The *ideal* sum for Decimal
instances would return the correctly rounded result (i.e., the exact result,
rounded to the current context just once using the current rounding mode). It
seems wrong to give a
Oscar Benjamin added the comment:
I've just checked over the new patch and it all looks good to me apart
from one quibble.
It is documented that statistics.sum() will respect rounding errors
due to decimal context (returning the same result that sum() would). I
would prefer it if statistics.sum
Steven D'Aprano added the comment:
On 19/08/13 23:15, Oscar Benjamin wrote:
So with the current implementation I can do:
from decimal import Decimal as D, localcontext, Context, ROUND_DOWN
data = [D(0.1375), D(0.2108), D(0.3061), D(0.0419)]
print(statistics.variance(data))
Oscar Benjamin added the comment:
On 19 August 2013 17:35, Steven D'Aprano rep...@bugs.python.org wrote:
Steven D'Aprano added the comment:
On 19/08/13 23:15, Oscar Benjamin wrote:
The final result is not accurate to 2 d.p. rounded down. This is
because the decimal context has affected
Steven D'Aprano added the comment:
Since I can't respond to the reviews, here's a revised patch. Summary of major
changes:
- median.* functions are now median_*
- mode now only returns a single value
- better integrate tests with Python regression suite
- cleanup tests as per Ezio's
Steven D'Aprano added the comment:
On 15/08/13 22:58, ezio.melo...@gmail.com wrote:
http://bugs.python.org/review/18606/diff/8927/Lib/statistics.py#newcode277
Lib/statistics.py:277: assert isinstance(x, float) and
isinstance(partials, list)
Is this a good idea?
I think so add_partials is
Antoine Pitrou added the comment:
A couple of comments about the test suite:
- I would like to see PEP8 test names, i.e. test_foo_and_bar rather than
testFooAndBar
- I don't think we need two separate test modules, it makes things more
confusing
--
Steven D'Aprano added the comment:
Merged two test suites into one, and PEP-ified the test names testSpam -
test_spam.
--
Added file: http://bugs.python.org/file31366/test_statistics.patch
___
Python tracker rep...@bugs.python.org
Steven D'Aprano added the comment:
Patch file for the stats module alone, without the tests.
--
Added file: http://bugs.python.org/file31367/statistics.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18606
Steven D'Aprano added the comment:
To anyone waiting for me to respond to rietveld reviews, I'm trying, I really
am, but I keep getting a django traceback.
This seems to have been reported before, three months ago:
http://psf.upfronthosting.co.za/roundup/meta/issue517
--
Mark Dickinson added the comment:
Steven: were you planning to start a discussion thread on python-dev for PEP
450? I see that there's some activity on python-list and on python-ideas, but
I think most core devs would expect the main discussions to happen on the
python-dev mailing list.
Changes by Ethan Furman et...@stoneleaf.us:
--
nosy: +ethan.furman
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18606
___
___
Python-bugs-list
Steven D'Aprano added the comment:
Attached is a patch containing the statistics reference implementation, after
considering feedback given here and on python-ideas, and tests.
--
keywords: +patch
Added file: http://bugs.python.org/file31286/statistics.patch
Terry J. Reedy added the comment:
Revised patch with tests modified to pass, as described in pydev post.
1. test. added to test_statistics_approx import
2. delete test_main and change ending of both to
if __name__ == '__main__':
unittest.main()
--
nosy: +terry.reedy
Added file:
Mark Dickinson added the comment:
About the implementation of sum: it's worth noting that the algorithm you're
using for floats depends on correct rounding of addition and subtraction, and
that that's not guaranteed. See the existing test (testFsum) in test_math for
more information, and
Mark Dickinson added the comment:
From the code:
# Also, like all dunder methods, we should call
# __float__ on the class, not the instance.
Why? I've never encountered this recommendation before. x.__float__() would
be clearer, IMO.
--
Mark Dickinson added the comment:
Why? I've never encountered this recommendation before. x.__float__()
would be clearer, IMO.
Hmm; it would be better if I engaged by brain before commenting. I guess the
point is that type(x).__float__(x) better matches the behaviour of the builtin
Mark Dickinson added the comment:
(We don't seem to care too much about the distinction in general, though:
there are a good few places in the std. lib. where obj.__index__() is used
instead of the more correct type(obj).__index__(obj).)
--
___
Steven D'Aprano added the comment:
On 09/08/13 21:49, Oscar Benjamin wrote:
I think that the argument `m` to variance, pvariance, stdev and pstdev
should be renamed to `mu` for pvariance/pstdev and `xbar` for
variance/stdev. The doc-strings should carefully distinguish that `mu`
is the
Steven D'Aprano added the comment:
On 12/08/13 19:21, Mark Dickinson wrote:
About the implementation of sum: it's worth noting that the algorithm you're
using for floats depends on correct rounding of addition and subtraction, and
that that's not guaranteed.
[...]
Steven: any thoughts
Mark Dickinson added the comment:
Okay, that works. I agree that not documenting add_partial is probably a good
plan.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18606
___
Oscar Benjamin added the comment:
On 12 August 2013 20:20, Steven D'Aprano rep...@bugs.python.org wrote:
On 12/08/13 19:21, Mark Dickinson wrote:
About the implementation of sum:
add_partial is no longer documented as a public function, so I'm open to
switching algorithms in the future.
Oscar Benjamin added the comment:
One small point:
I think that the argument `m` to variance, pvariance, stdev and pstdev
should be renamed to `mu` for pvariance/pstdev and `xbar` for
variance/stdev. The doc-strings should carefully distinguish that `mu`
is the true/population mean and `xbar`
Steven D'Aprano added the comment:
On 31/07/13 20:23, Antoine Pitrou added the comment:
I suppose you should write a PEP for the module inclusion proposal
Done.
http://www.python.org/dev/peps/pep-0450/
I hope to have an updated reference implementation, plus unittests, up later
today or
Stephen J. Turnbull added the comment:
A few small comments and nits.
1. I'm with the author on the question of a sum function in this module. The
arguments that builtin sum isn't accurate enough, and neither is math.fsum for
cases where all data is of infinite precision, are enough for me.
Changes by Oscar Benjamin oscar.j.benja...@gmail.com:
--
nosy: +oscarbenjamin
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18606
___
___
Steven D'Aprano added the comment:
On 03/08/13 13:22, Alexander Belopolsky wrote:
Alexander Belopolsky added the comment:
The implementation of median and mode families of functions as classes is
clever,
So long as it is not too clever.
but I am not sure it is a good idea to return
Changes by Mark Dickinson dicki...@gmail.com:
--
nosy: +mark.dickinson
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18606
___
___
Mark Dickinson added the comment:
I too find the use of a class that'll never be instantiated peculiar.
As you say, there's no state to be stored. So why not simply have separate
functions `median`, `median_low`, `median_high`, `median_grouped`, etc.?
--
Steven D'Aprano added the comment:
On 06/08/13 03:08, Mark Dickinson wrote:
I too find the use of a class that'll never be instantiated peculiar.
I'll accept unusual, but not peculiar. It's an obvious extension to classes
being first-class objects. We use classes as objects very frequently,
Alexander Belopolsky added the comment:
On Mon, Aug 5, 2013 at 2:14 PM, Steven D'Aprano rep...@bugs.python.orgwrote:
As you say, there's no state to be stored. So why not simply have
separate functions `median`, `median_low`, `median_high`, `median_grouped`,
etc.?
Why have a
Mark Dickinson added the comment:
My only objection is to having a class xyz such that isinstance(xyz(..),
xyz) is false.
Yep. Use a set of functions (median, median_low); use an instance of a class
as Alexander describes; use a single median function that takes an optional
method
Daniel Stutzbach added the comment:
As the person originally trying to take the mean of timedelta objects, I'm
personally fine with the workaround of:
py m = statistics.mean([x.total_seconds() for x in data])
py td(seconds=m)
datetime.timedelta(2, 43200)
At the time I was trying to take the
Ronald Oussoren added the comment:
As noted before statistics.sum seems to have the same functionality as
math.fsum.
Statistics.add_partial, which does the majority of the work, also references
the same cookbook recipe as the math.fsum documentation.
IMHO statistics.sum should be removed.
Steven D'Aprano added the comment:
On 03/08/13 13:02, Alexander Belopolsky wrote:
Alexander Belopolsky added the comment:
Is there a reason why there is no review link? Could it be because the
file is uploaded as is rather than as a patch?
I cannot answer that question, sorry.
In any
Vajrasky Kok added the comment:
Is there a reason why there is no 'review' link? Could it be because the file
is uploaded as is rather than as a patch?
I think I can answer this question. The answer is yes. You can have review
only if you use diff not raw file.
The original poster, Steven
Changes by Tshepang Lekhonkhobe tshep...@gmail.com:
--
nosy: +tshepang
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18606
___
___
Alexander Belopolsky added the comment:
Here is the use-case that was presented to support adding additional operations
on timedelta objects:
I'm conducting a series of observation experiments where I
measure the duration of an event. I then want to do various
statistical analysis such as
Steven D'Aprano added the comment:
On 04/08/13 05:31, Alexander Belopolsky wrote:
Alexander Belopolsky added the comment:
Here is the use-case that was presented to support adding additional
operations on timedelta objects:
I'm conducting a series of observation experiments where I
Changes by Christian Heimes li...@cheimes.de:
--
nosy: +christian.heimes
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18606
___
___
Alexander Belopolsky added the comment:
Once we start special-casing types, where will it end?
At the point where all stdlib types are special-cased. :-)
In the meantime, there's a simple way to do this:
py from datetime import timedelta as td
py data = [td(2), td(1), td(3), td(4)]
py m =
Gregory P. Smith added the comment:
note,
http://docs.scipy.org/doc/scipy/reference/stats.html#statistical-functions is a
very popular module for statistics in Python.
One of the more frequent things I see people include the entire beast of a code
base (scipy and numpy) for is the student's
Alexander Belopolsky added the comment:
Is there a reason why there is no review link? Could it be because the file
is uploaded as is rather than as a patch?
In any case, I have a question about this code in sum:
# Convert running total to a float. See comment below for
Alexander Belopolsky added the comment:
The implementation of median and mode families of functions as classes is
clever, but I am not sure it is a good idea to return something other than an
instance of the class from __new__(). I would prefer to see a more traditional
implementation along
New submission from Steven D'Aprano:
I proposed adding a statistics module to the standard library some time ago,
and received some encouragement:
http://mail.python.org/pipermail/python-ideas/2011-September/011524.html
Real life intervened, plus a bad case of over-engineering, but over the
Antoine Pitrou added the comment:
I suppose you should write a PEP for the module inclusion proposal (and for a
summary of the API).
--
nosy: +pitrou
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18606
Ronald Oussoren added the comment:
At first glance statistics.sum does the same as math.fsum (and statistics.
add_partial seems to be a utility for implementing sum).
I agree that a PEP would be useful.
--
nosy: +ronaldoussoren
___
Python tracker
70 matches
Mail list logo
