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 Jeffrey.Kintscher, mark.dickinson, pablogsal, rhettinger, tim.peters, veky
Date 2020-08-06.19:27:23
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1596742043.37.0.915533303081.issue41458@roundup.psfhosted.org>
In-reply-to
Content
[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.
History
Date User Action Args
2020-08-06 19:27:23rhettingersetrecipients: + rhettinger, tim.peters, mark.dickinson, veky, pablogsal, Jeffrey.Kintscher
2020-08-06 19:27:23rhettingersetmessageid: <1596742043.37.0.915533303081.issue41458@roundup.psfhosted.org>
2020-08-06 19:27:23rhettingerlinkissue41458 messages
2020-08-06 19:27:23rhettingercreate