Raymond Hettinger <raymond.hettin...@gmail.com> added the comment:
> 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. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue35904> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
