Re: [Numpy-discussion] deprecations for 1.6; assert_almost_equal
On Mon, Mar 7, 2011 at 7:53 PM, Pauli Virtanen p...@iki.fi wrote: Mon, 07 Mar 2011 06:39:20 -0500, josef.pktd wrote: Doc update committed in f527b49a. Why does assert_allclose have atol=0, while np.allclose has rtol=1.e-5, atol=1.e-8 ? Probably no reason, it should be fixed. I'm guessing that whoever wrote assert_allclose wanted only relative tolerance by default, which makes sense to me - it's a little easier to use than atol + rtol * desired. But either way is fine with me. Cheers, Ralf ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] deprecations for 1.6; assert_almost_equal
Mon, 07 Mar 2011 11:03:17 +0800, Ralf Gommers wrote: [clip] If anyone has new deprecations they want to put in for 1.6, discussing them now would be good. I found one item in Trac, #1543. The proposal in the ticket is to deprecate assert_almost_equal because it is quite badly behaved. This function is quite widely used however (also in scipy and presumably in third party code), so it will be a real pain if it starts spewing out warnings. I propose instead to just add a note at the top of the assert_almost_equal docstring that assert_array_max_ulp or assert_tol_equal (to be added from scipy.special in 1.6) should be used instead for new code. Numpy 1.5 has `assert_allclose` which is functionally equivalent to the proposed `assert_tol_equal`, so no new functions need to be added. I'm OK with documentation-only recommendation. Pauli ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] deprecations for 1.6; assert_almost_equal
On Mon, Mar 7, 2011 at 4:10 AM, Pauli Virtanen p...@iki.fi wrote: Mon, 07 Mar 2011 11:03:17 +0800, Ralf Gommers wrote: [clip] If anyone has new deprecations they want to put in for 1.6, discussing them now would be good. I found one item in Trac, #1543. The proposal in the ticket is to deprecate assert_almost_equal because it is quite badly behaved. This function is quite widely used however (also in scipy and presumably in third party code), so it will be a real pain if it starts spewing out warnings. I propose instead to just add a note at the top of the assert_almost_equal docstring that assert_array_max_ulp or assert_tol_equal (to be added from scipy.special in 1.6) should be used instead for new code. Numpy 1.5 has `assert_allclose` which is functionally equivalent to the proposed `assert_tol_equal`, so no new functions need to be added. I'm OK with documentation-only recommendation. I also think assert_almost_equal should not be depreciated. Besides being very heavily used, it is also the most appropriate test for many statistical tests. Test statistics like t-tests and p-values have an absolute scale, and only a few decimals make statistical sense. The tolerance for calculations (minimization, numerical differentiation and integration) is often only targeted for this. Changing the signature just to replicate it with assert_allclose is a pain without any gain. And going over all the tests to see what the appropriate relative error is, is a lot of work. But we have some tickets in scipy stats to improve numerical precision, beyond some decimals, and relative tolerance would be useful in those cases. I didn't know about assert_allclose and more advertising will help to use it more often for new tests. Why does assert_allclose have atol=0, while np.allclose has rtol=1.e-5, atol=1.e-8 ? What's the status on np.testing.assert_approx_equal, I would have liked to use it more often, except it doesn't work on arrays. Josef Pauli ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] deprecations for 1.6; assert_almost_equal
Mon, 07 Mar 2011 06:39:20 -0500, josef.pktd wrote: [clip] Why does assert_allclose have atol=0, while np.allclose has rtol=1.e-5, atol=1.e-8 ? Probably no reason, it should be fixed. What's the status on np.testing.assert_approx_equal, I would have liked to use it more often, except it doesn't work on arrays. It's probably going to stay as well. The test routines have a common framework for working with arrays, but maybe that routine dates from way back, and wasn't ported to use it. Both the assert_approx_equal and assert_almost_equal also have the built-in ugliness of specifying precision via decimals= which is somewhat clumsy for numerical work. -- Pauli Virtanen ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] deprecations for 1.6; assert_almost_equal
On Mon, Mar 7, 2011 at 6:53 AM, Pauli Virtanen p...@iki.fi wrote: Mon, 07 Mar 2011 06:39:20 -0500, josef.pktd wrote: [clip] Why does assert_allclose have atol=0, while np.allclose has rtol=1.e-5, atol=1.e-8 ? Probably no reason, it should be fixed. What's the status on np.testing.assert_approx_equal, I would have liked to use it more often, except it doesn't work on arrays. It's probably going to stay as well. The test routines have a common framework for working with arrays, but maybe that routine dates from way back, and wasn't ported to use it. Both the assert_approx_equal and assert_almost_equal also have the built-in ugliness of specifying precision via decimals= which is somewhat clumsy for numerical work. assert_approx_equal checks for signigicant digits in decimal system, which looks like it's easy to interpret. I don't have much idea what a nulp is, and whether it's machine dependent. np.testing.assert_array_max_ulp(x, np.ones(10)) Traceback (most recent call last): File pyshell#21, line 1, in module np.testing.assert_array_max_ulp(x, np.ones(10)) File C:\Programs\Python25\Lib\site-packages\numpy\testing\utils.py, line 1231, in assert_array_max_ulp ret = nulp_diff(a, b, dtype) File C:\Programs\Python25\Lib\site-packages\numpy\testing\utils.py, line 1271, in nulp_diff raise NotImplementedError(_nulp not implemented for complex array) NotImplementedError: _nulp not implemented for complex array Josef -- Pauli Virtanen ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] deprecations for 1.6; assert_almost_equal
Mon, 07 Mar 2011 08:30:11 -0500, josef.pktd wrote: [clip] assert_approx_equal checks for signigicant digits in decimal system, which looks like it's easy to interpret. Ditto for tolerance=1e-7, which has the advantage that it's what print abs(desired-actual) prints. I don't have much idea what a nulp is, and whether it's machine dependent. It's the number of floating point values between the desired and the actual results --- this depends only on the fp type. It is *the* correct measure when you want uniform accuracy across the range of all floating point values. For instance, this is quite useful for special functions, whose range of values typically vary widely, but for which one still wants to have accuracy which is as good as possible. -- Pauli Virtanen ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] deprecations for 1.6; assert_almost_equal
On Mon, Mar 7, 2011 at 8:37 AM, Pauli Virtanen p...@iki.fi wrote: Mon, 07 Mar 2011 08:30:11 -0500, josef.pktd wrote: [clip] assert_approx_equal checks for signigicant digits in decimal system, which looks like it's easy to interpret. Ditto for tolerance=1e-7, which has the advantage that it's what print abs(desired-actual) prints. Ok, it took me a while to figure out what the issue is, atol is more intuitive then decimal, especially since decimal has the half point/rounding behavior that I'm never quite sure about. I initially thought the issue is between atol versus rtol versus nulp. Is there a reason that assert_array_almost_equal uses around(z, decimal) = 10.0**(-decimal) while the last part of assert _almost_equal is if round(abs(desired - actual),decimal) != 0 I don't have much idea what a nulp is, and whether it's machine dependent. It's the number of floating point values between the desired and the actual results --- this depends only on the fp type. It is *the* correct measure when you want uniform accuracy across the range of all floating point values. For instance, this is quite useful for special functions, whose range of values typically vary widely, but for which one still wants to have accuracy which is as good as possible. Is nulp_diff exposed somewhere? It looks like a useful functions to write nulp tests, and I only saw it in the source. Josef -- Pauli Virtanen ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
