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

On Fri, Jan 23, 2015 at 7:36 AM, Antoine Pitrou <solipsis@pitrou.net> wrote:
On Thu, 22 Jan 2015 16:40:14 -0800
Chris Barker <chris.barker@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

repeat:

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)