Raymond Hettinger <raymond.hettin...@gmail.com> added the comment:
[Uncle Timmy] > I'm skeptical of the need for - and wisdom of - this. Granted, the need is not common. On the other hand, if we can do it cheaply, why wouldn't we? Unnecessary overflow or underflow is never a desirable outcome. Currently, users do not have an easy and fast way to avoid that outcome. This comes up a lot when I use or teach how to apply Hypothesis to test floating point code. That tool makes you acutely aware of how much your functions have to be constrained to assure a useful output. And if you aren't satisfied with those constraints, it can be hard to fix unless you have robust primitives. Presumably that is why numpy uses pairwise summation instead of straight addition for example. To me, this is in the same category fixing the overflow error in bisect or using scaling in hypot() to avoid overflow or underflow. The core idea is to make the primitives as robust as possible if it can be done with only a minor performance impact. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue41458> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
