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

[Pauli Virtanen]

18.07.2014 21:03, josef.pktd at gmail.com kirjoitti:
[clip]
> Of course you can change it.
> 
> But the testing functions are code and very popular code.
> 
> And if you break backwards compatibility, then I wouldn't mind reviewing a
> pull request for statsmodels that adds 300 to 400 `atol=0` to the unit
> tests. :)

10c:

Scipy has 960 of those, and atol ~ 0 is required in some cases
(difficult to say in how big percentage without review). The default of
atol=1e-8 is pretty large.

There's ~60 instances of allclose(), most of which are in tests. About
half of those don't have atol=, whereas most have rtol.

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).

    ***

Consistency would be nice, especially in not having traps like

	assert_allclose(a, b, eps)
	->
	assert_(not np.allclose(a, b, eps))

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

If the change is made, it needs to be noted in the release notes. I
think the number of project authors who relied on that the default was
atol=0 is not so big.

(In other news, we should discourage use of assert_almost_equal, by
telling people to use assert_allclose instead in the docstring at the
least. It has only atol= and it specifies it in a very cumbersome log10
basis...)

-- 
Pauli Virtanen