18.07.2014 21:03, josef.p...@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 _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion