
On 24 January 2015 at 03:12, Ethan Furman <ethan@stoneleaf.us> wrote:
On 01/23/2015 07:36 AM, Antoine Pitrou wrote:
On Thu, 22 Jan 2015 16:40:14 -0800 Chris Barker wrote:
Expected Uses =============
The primary expected use case is various forms of testing -- "are the results computed near what I expect as a result?" This sort of test may or may not be part of a formal unit testing suite.
I don't think the proposal fits the bill. For testing you want a function that is both 1) quite rigorous (i.e. checks equality within a defined number of ulps) 2) handles all special cases in a useful way (i.e. zeros, including distinguishing between positive and negative zeros, infinities, NaNs etc.).
I disagree -- this function is not meant for mathematicians, but for the non-maths person who needs something that works. Will there be situations where it doesn't work? Certainly. Will they be surprising? Possibly.
Note that the key requirement here should be "provide a binary float comparison function that is significantly less wrong than the current 'a == b'". "a == b" is the competition here, not the more correct versions available in other libraries. As far as semantics go, I would expect the new function to be a near drop-in replacement for https://docs.python.org/3/library/unittest.html#unittest.TestCase.assertAlmo... in a testing context. The reason I view the proposal in the PEP as problematic is because it is approaching the problem *like a scientist*, rather than as someone who last studied math in high school. The unittest module definition relies on a very simple set of assumptions: 1. The user understands how arithmetic subtraction works 2. The user understands how decimal rounding works 3. The user understands how absolute deltas work This is a "good enough" answer that handles a wide variety of real world use cases, and is very easy to understand. Most importantly, it provides a hint that when working with floating point numbers, "==" is likely to cause you grief. This simple definition *isn't* really good enough for statistical or scientific use cases, but in those cases you should be using a statistical or scientific computation library with a more sophisticated definition of near equality. Regards, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia