This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author rhettinger
Recipients josh.r, rhettinger, steven.daprano, tim.peters
Date 2019-02-06.04:07:25
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1549426046.05.0.656242406738.issue35904@roundup.psfhosted.org>
In-reply-to
Content
> Correctness over speed.

Are you saying that "fsum(seq) / len(seq)" is incorrect because on some older builds there is a rare possibility of an error of 1 unit in the last place?  Just about everyone who uses this module will not care one whit about that.  ISTM, a requirement for exactness violates "practicality beats purity".  We really don't want to be in the position of advising people to never use this module because of design choices that aren't in line with user needs.

> It is easier to speed up a correct but slow function 
> than to correct a fast but buggy one.

Taken to an extreme, this could be used justify a BubbleSort.  In the case of statistics.mean(), slowness of three orders of magnitude makes this a nearly catastrophic choice for real world use.

> I don't like the naming symmetry between fsum and fmean;

Any reasonable name will suffice.  I suggested an f prefix that could be taken to mean that it is "fast" or that it returns a "float".  It isn't much different than isqrt() for an integer square root.

> numpy already exists for people who need insane speed for these algorithms 
> and are willing to compromise accuracy;

Let's see what Steven and Tim think about this.
History
Date User Action Args
2019-02-06 04:07:27rhettingersetrecipients: + rhettinger, tim.peters, steven.daprano, josh.r
2019-02-06 04:07:26rhettingersetmessageid: <1549426046.05.0.656242406738.issue35904@roundup.psfhosted.org>
2019-02-06 04:07:26rhettingerlinkissue35904 messages
2019-02-06 04:07:25rhettingercreate