Steven D'Aprano <steve+pyt...@pearwood.info> added the comment:
In the PEP, I did say that I was making no attempt to compete with numpy for speed, and that correctness was more important than speed. That doesn't mean I don't care about speed. Nor do I necessarily care about absolute precision when given nothing but float arguments. Mark suggests that using fsum() will be accurate to within 1.5 ulp which satisfies me for float arguments. I doubt that stdev etc would be able to promise that accuracy, so provided your data is all floats, that seems like a pretty good result for the mean. But I'm not super-keen on having two separate mean() functions if that opens the floodgates to people wanting every statistics function to grow a fast-but-floats-only twin. That would make me sad. But maybe mean() is special enough to justify twinning it. In my ideal world, I'd have a single mean() function that had a fast-path for float data, but would automatically drop down to a slower but more accurate path for other types, out-of-range data, etc. I believe that the the built-in sum() function does something like this. When I say "more accurate", this isn't a complaint about fsum(). It refers to the limitation of floats themselves. Call me Mr Silly if you like, but if I need to take the average of numbers bigger than 2**1074 I would like to be able to, even if it takes a bit longer :-) ---------- _______________________________________ 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
