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

Guido van Rossum guido at python.org
Fri Jan 23 18:41:24 CET 2015

On Fri, Jan 23, 2015 at 8:51 AM, Chris Barker <chris.barker at noaa.gov> wrote:

> On Fri, Jan 23, 2015 at 7:36 AM, Antoine Pitrou <solipsis at pitrou.net>
> wrote:
>> On Thu, 22 Jan 2015 16:40:14 -0800
>> Chris Barker <chris.barker at noaa.gov> 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)
> It depends on what you are testing -- I tried to be explicite that this
> was not intended for testing the accuracy of numerical algorithms, for
> instance. Rather, it's best use case is testing to see whether you have
> introduced a big 'ol bug that completely changed your result -- have you
> got in the ballark.

Maybe the confusion here is around the use of "test". To some, that means
"unit test" or some other way of testing software. But I hope that's not
the main use case. Let's look at Newton's algorithm for computing a square
root. It's something like

def sqrt(x):
    new_guess = 1
        guess = new_guess
        new_guess = avg(guess, x/guess)  # Not sure if I've got this right
    until guess is close enough to new guess
    return guess

This seems a place where a decent "is close enough" definition would help.
(Even though this particular algorithm usually converges so rapidly that
you can get a result that's correct to within an ulp or so -- other
approximations might not.)

> Something similar is in Boost, is in numpy, and n any number of other
> places. It is clearly useful. THat doesn't mean it has to go in the stdlib,
> but it is useful in many cases.
> As for the ulps test -- can you suggest a way to do that, while also
> providing a simple definition of tolerance that casual users can understand
> and use (and have a reasonable default? I know I can't.

Isn't an ulp just a base-2 way of specifying precision scaled so that 1 ulp
is the low bit of the mantissa in IEEE fp?

> Note that some of the feedback on the PEP as is is that it's too hard to
> understand already! (without better docs, anyway)
>> handles all special cases in a useful way
>> (i.e. zeros, including distinguishing between positive and negative
>> zeros, infinities, NaNs etc.).
> zero, inf, -inf, NaN are all handles, I think correctly. And if -0.0 is
> not cloe to 0.0, I dont know what is ;-)
> (there is a test to make sure that's true actually)
> If you want to make the  distinction between -0.0 and 0.0, then you don't
> want a "close" or "approximate" test.
>> As someone who wrote such a function for Numba, what you're proposing
>> would not be a suitable replacement.
> I never expected it would be a replacement for what is needed for a
> project like numba.
> -Chris
--Guido van Rossum (python.org/~guido)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20150123/4dd3f002/attachment.html>

More information about the Python-ideas mailing list