[Python-ideas] PEP 485: A Function for testing approximate equality

[Nick Coghlan]

On 24 January 2015 at 03:12, Ethan Furman <ethan at 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.assertAlmostEqual
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 at gmail.com   |   Brisbane, Australia