[Numpy-discussion] `allclose` vs `assert_allclose`

Chris Barker chris.barker at noaa.gov
Fri Jul 18 15:13:21 EDT 2014


On Fri, Jul 18, 2014 at 11:47 AM, Pauli Virtanen <pav at iki.fi> wrote:

> Using allclose in non-test code without specifying both tolerances
> explicitly is IMHO a sign of sloppiness, as the default tolerances are
> both pretty big (and atol != 0 is not scale-free).
>

using it without specifying tolerances is sloppy in ANY use case.

Bumping the tolerances in assert_allclose() up to match allclose() will
> probably not break code, but it can render some tests ineffective.
>

being a bit pedantic here, but rendering a test ineffective IS breaking
code.

And I'd rather a change break my tests than render them ineffective -- if
they break, I'll go look at them. If they are rendered ineffective, I'll
never notice.

Curious here -- is atol necessary for anything OTHER than near zero?

I can see that in a given case, you may know exactly what range of values
to expect (and everything in the array is of the same order of magnitude),
but an appropriate rtol would work there too. If only zero testing is
needed, then atol=0 makes sense as a default. (or maybe atol=eps)

Note:
"""
The relative difference (`rtol` * abs(`b`)) and the absolute difference
`atol` are added together to compare against the absolute difference
between `a` and `b`.
"""
Which points to seting atol=0 for the default as well, or it can totally
mess up a test on very small numbers.

I'll bet there is a LOT of sloppy use of these out  the wild (I know I've
been sloppy), and Im starting to think that atol=0 is the ONLY appropriate
default for the sloppy among us for instance:

In [40]: a1 = np.array([1e-100])

In [41]: a2 = np.array([1.00000001e-100])

In [42]: np.all
np.all       np.allclose  np.alltrue

In [42]: np.allclose(a1, a2, rtol=1e-10)
Out[42]: True

In [43]: np.allclose(a1, a2, rtol=1e-10, atol=0)
Out[43]: False

That's really not good.

By the way:
Definition:  np.allclose(a, b, rtol=1e-05, atol=1e-08)

Really? those are HUGE defaults for double-precision math. I can't believe
I haven't looked more closely at this before!

-Chris

-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R            (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Chris.Barker at noaa.gov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20140718/c143a1ad/attachment.html>


More information about the NumPy-Discussion mailing list