DST I precision (was ANN: SciPy 0.11.0 release candidate 1)
On Sat, Jul 21, 2012 at 6:06 PM, John Hassler <hasslerjc@comcast.net> wrote:
On 7/21/2012 10:43 AM, Ralf Gommers wrote:
On Fri, Jul 20, 2012 at 9:57 PM, John Hassler <hasslerjc@comcast.net>wrote:
======================================================================
FAIL: test_definition (test_real_transforms.TestDSTIDouble)
---------------------------------------------------------------------- Traceback (most recent call last): File "C:\Python32\lib\site-packages\scipy\fftpack\tests\test_real_transforms.py", line 213, in test_definition err_msg="Size %d failed" % i) File "C:\Python32\lib\site-packages\numpy\testing\utils.py", line 800, in assert_array_almost_equal header=('Arrays are not almost equal to %d decimals' % decimal)) File "C:\Python32\lib\site-packages\numpy\testing\utils.py", line 636, in assert_array_compare raise AssertionError(msg) AssertionError: Arrays are not almost equal to 15 decimals Size 256 failed (mismatch 3.515625%) x: array([ 1.00000000e+00, -5.03902743e-01, 3.33300126e-01, -2.51913719e-01, 1.99940224e-01, -1.67900640e-01, 1.42771743e-01, -1.25881543e-01, 1.11000399e-01,... y: array([ 1.00000000e+00, -5.03902743e-01, 3.33300126e-01, -2.51913719e-01, 1.99940224e-01, -1.67900640e-01, 1.42771743e-01, -1.25881543e-01, 1.11000399e-01,...
This looks like the test precision being a little too high. Could you adjust it to decimal=14 or lower, and tell us when the test passes on your machine?
Thanks, Ralf
decimal = 14 passes. john
This test and the failure look a bit odd, so I just want to make sure: is it OK to lower the test precision? DST II passes with decimal=15 and DST III with decimal=16, so not sure why DST I is worse. Looks like this test could use some improvement: # XXX: we divide by np.max(y) because the tests fail otherwise. We # should really use something like assert_array_approx_equal. The # difference is due to fftw using a better algorithm w.r.t error # propagation compared to the ones from fftpack. assert_array_almost_equal(y / np.max(y), yr / np.max(y), decimal=self.dec, err_msg="Size %d failed" % i) Any takers? Ralf
On Sat, Jul 21, 2012 at 9:57 PM, Ralf Gommers <ralf.gommers@googlemail.com>wrote:
On Sat, Jul 21, 2012 at 6:06 PM, John Hassler <hasslerjc@comcast.net>wrote:
On 7/21/2012 10:43 AM, Ralf Gommers wrote:
On Fri, Jul 20, 2012 at 9:57 PM, John Hassler <hasslerjc@comcast.net>wrote:
======================================================================
FAIL: test_definition (test_real_transforms.TestDSTIDouble)
---------------------------------------------------------------------- Traceback (most recent call last): File "C:\Python32\lib\site-packages\scipy\fftpack\tests\test_real_transforms.py", line 213, in test_definition err_msg="Size %d failed" % i) File "C:\Python32\lib\site-packages\numpy\testing\utils.py", line 800, in assert_array_almost_equal header=('Arrays are not almost equal to %d decimals' % decimal)) File "C:\Python32\lib\site-packages\numpy\testing\utils.py", line 636, in assert_array_compare raise AssertionError(msg) AssertionError: Arrays are not almost equal to 15 decimals Size 256 failed (mismatch 3.515625%) x: array([ 1.00000000e+00, -5.03902743e-01, 3.33300126e-01, -2.51913719e-01, 1.99940224e-01, -1.67900640e-01, 1.42771743e-01, -1.25881543e-01, 1.11000399e-01,... y: array([ 1.00000000e+00, -5.03902743e-01, 3.33300126e-01, -2.51913719e-01, 1.99940224e-01, -1.67900640e-01, 1.42771743e-01, -1.25881543e-01, 1.11000399e-01,...
This looks like the test precision being a little too high. Could you adjust it to decimal=14 or lower, and tell us when the test passes on your machine?
Thanks, Ralf
decimal = 14 passes. john
This test and the failure look a bit odd, so I just want to make sure: is it OK to lower the test precision? DST II passes with decimal=15 and DST III with decimal=16, so not sure why DST I is worse. Looks like this test could use some improvement:
# XXX: we divide by np.max(y) because the tests fail otherwise. We # should really use something like assert_array_approx_equal. The # difference is due to fftw using a better algorithm w.r.t error # propagation compared to the ones from fftpack. assert_array_almost_equal(y / np.max(y), yr / np.max(y), decimal=self.dec, err_msg="Size %d failed" % i)
Actually I get a failure myself for DSTIIIDouble, only with Python 2.4. It seems that the DST test tolerances are set much higher than the DCT ones. Lowering them all to decimal=14 would make sense to avoid further failures. Any objections? Ralf
Nope. The tolerances are based on what worked on my macbook, but I didn't have machines to do further testing. The correct values are from fftw. Compared to fftw the algorithms in fftpack are not as accurate. That and i would be very careful about believing the 15th decimal of anything. -matt On Mon, Jul 23, 2012 at 1:37 AM, Ralf Gommers <ralf.gommers@googlemail.com> wrote:
On Sat, Jul 21, 2012 at 9:57 PM, Ralf Gommers <ralf.gommers@googlemail.com> wrote:
On Sat, Jul 21, 2012 at 6:06 PM, John Hassler <hasslerjc@comcast.net> wrote:
On 7/21/2012 10:43 AM, Ralf Gommers wrote:
On Fri, Jul 20, 2012 at 9:57 PM, John Hassler <hasslerjc@comcast.net> wrote:
====================================================================== FAIL: test_definition (test_real_transforms.TestDSTIDouble)
---------------------------------------------------------------------- Traceback (most recent call last): File "C:\Python32\lib\site-packages\scipy\fftpack\tests\test_real_transforms.py", line 213, in test_definition err_msg="Size %d failed" % i) File "C:\Python32\lib\site-packages\numpy\testing\utils.py", line 800, in assert_array_almost_equal header=('Arrays are not almost equal to %d decimals' % decimal)) File "C:\Python32\lib\site-packages\numpy\testing\utils.py", line 636, in assert_array_compare raise AssertionError(msg) AssertionError: Arrays are not almost equal to 15 decimals Size 256 failed (mismatch 3.515625%) x: array([ 1.00000000e+00, -5.03902743e-01, 3.33300126e-01, -2.51913719e-01, 1.99940224e-01, -1.67900640e-01, 1.42771743e-01, -1.25881543e-01, 1.11000399e-01,... y: array([ 1.00000000e+00, -5.03902743e-01, 3.33300126e-01, -2.51913719e-01, 1.99940224e-01, -1.67900640e-01, 1.42771743e-01, -1.25881543e-01, 1.11000399e-01,...
This looks like the test precision being a little too high. Could you adjust it to decimal=14 or lower, and tell us when the test passes on your machine?
Thanks, Ralf
decimal = 14 passes. john
This test and the failure look a bit odd, so I just want to make sure: is it OK to lower the test precision? DST II passes with decimal=15 and DST III with decimal=16, so not sure why DST I is worse. Looks like this test could use some improvement:
# XXX: we divide by np.max(y) because the tests fail otherwise. We # should really use something like assert_array_approx_equal. The # difference is due to fftw using a better algorithm w.r.t error # propagation compared to the ones from fftpack. assert_array_almost_equal(y / np.max(y), yr / np.max(y), decimal=self.dec, err_msg="Size %d failed" % i)
Actually I get a failure myself for DSTIIIDouble, only with Python 2.4. It seems that the DST test tolerances are set much higher than the DCT ones. Lowering them all to decimal=14 would make sense to avoid further failures. Any objections?
Ralf
_______________________________________________ SciPy-Dev mailing list SciPy-Dev@scipy.org http://mail.scipy.org/mailman/listinfo/scipy-dev
On Tue, Jul 24, 2012 at 10:09 PM, Matt Terry <matt.terry@gmail.com> wrote:
Nope. The tolerances are based on what worked on my macbook, but I didn't have machines to do further testing.
Thanks Matt. Changed in master now. Ralf
The correct values are from fftw. Compared to fftw the algorithms in fftpack are not as accurate. That and i would be very careful about believing the 15th decimal of anything.
-matt
On Mon, Jul 23, 2012 at 1:37 AM, Ralf Gommers <ralf.gommers@googlemail.com> wrote:
On Sat, Jul 21, 2012 at 9:57 PM, Ralf Gommers <
ralf.gommers@googlemail.com>
wrote:
On Sat, Jul 21, 2012 at 6:06 PM, John Hassler <hasslerjc@comcast.net> wrote:
On 7/21/2012 10:43 AM, Ralf Gommers wrote:
On Fri, Jul 20, 2012 at 9:57 PM, John Hassler <hasslerjc@comcast.net> wrote:
====================================================================== FAIL: test_definition (test_real_transforms.TestDSTIDouble)
---------------------------------------------------------------------- Traceback (most recent call last): File
"C:\Python32\lib\site-packages\scipy\fftpack\tests\test_real_transforms.py",
line 213, in test_definition err_msg="Size %d failed" % i) File "C:\Python32\lib\site-packages\numpy\testing\utils.py", line 800, in assert_array_almost_equal header=('Arrays are not almost equal to %d decimals' % decimal)) File "C:\Python32\lib\site-packages\numpy\testing\utils.py", line 636, in assert_array_compare raise AssertionError(msg) AssertionError: Arrays are not almost equal to 15 decimals Size 256 failed (mismatch 3.515625%) x: array([ 1.00000000e+00, -5.03902743e-01, 3.33300126e-01, -2.51913719e-01, 1.99940224e-01, -1.67900640e-01, 1.42771743e-01, -1.25881543e-01, 1.11000399e-01,... y: array([ 1.00000000e+00, -5.03902743e-01, 3.33300126e-01, -2.51913719e-01, 1.99940224e-01, -1.67900640e-01, 1.42771743e-01, -1.25881543e-01, 1.11000399e-01,...
This looks like the test precision being a little too high. Could you adjust it to decimal=14 or lower, and tell us when the test passes on your machine?
Thanks, Ralf
decimal = 14 passes. john
This test and the failure look a bit odd, so I just want to make sure: is it OK to lower the test precision? DST II passes with decimal=15 and DST III with decimal=16, so not sure why DST I is worse. Looks like this test could use some improvement:
# XXX: we divide by np.max(y) because the tests fail otherwise. We # should really use something like assert_array_approx_equal. The # difference is due to fftw using a better algorithm w.r.t error # propagation compared to the ones from fftpack. assert_array_almost_equal(y / np.max(y), yr / np.max(y), decimal=self.dec, err_msg="Size %d failed" % i)
Actually I get a failure myself for DSTIIIDouble, only with Python 2.4. It seems that the DST test tolerances are set much higher than the DCT ones. Lowering them all to decimal=14 would make sense to avoid further failures. Any objections?
Ralf
_______________________________________________ SciPy-Dev mailing list SciPy-Dev@scipy.org http://mail.scipy.org/mailman/listinfo/scipy-dev
_______________________________________________ SciPy-Dev mailing list SciPy-Dev@scipy.org http://mail.scipy.org/mailman/listinfo/scipy-dev
participants (2)
-
Matt Terry -
Ralf Gommers