ANN: scipy 0.8.0 release candidate 3
I'm pleased to announce the availability of the third release candidate of SciPy 0.8.0. The only changes compared to rc2 are a fix for a regression in interpolate.Rbf and some fixes for failures on 64-bit Windows. If no more problems are reported, the final release will be available in one week. SciPy is a package of tools for science and engineering for Python. It includes modules for statistics, optimization, integration, linear algebra, Fourier transforms, signal and image processing, ODE solvers, and more. This release candidate release comes one and a half year after the 0.7.0 release and contains many new features, numerous bug-fixes, improved test coverage, and better documentation. Please note that SciPy 0.8.0rc3 requires Python 2.4-2.6 and NumPy 1.4.1 or greater. For more information, please see the release notes: http://sourceforge.net/projects/scipy/files/scipy/0.8.0rc3/NOTES.txt/view<http://sourceforge.net/projects/scipy/files/scipy/0.8.0rc1/NOTES.txt/view> You can download the release from here: https://sourceforge.net/projects/scipy/ Python 2.5/2.6 binaries for Windows and OS X are available, as well as source tarballs for other platforms and the documentation in pdf form. Thank you to everybody who contributed to this release. Enjoy, Ralf
Looks good for me now running py2.7 on oxs compiled 64bit Ran 4407 tests in 119.221s OK (KNOWNFAIL=19, SKIP=35) <nose.result.TextTestResult run=4407 errors=0 failures=0> Vincent On Thu, Jul 15, 2010 at 9:27 AM, Ralf Gommers <ralf.gommers@googlemail.com> wrote:
I'm pleased to announce the availability of the third release candidate of SciPy 0.8.0. The only changes compared to rc2 are a fix for a regression in interpolate.Rbf and some fixes for failures on 64-bit Windows. If no more problems are reported, the final release will be available in one week.
SciPy is a package of tools for science and engineering for Python. It includes modules for statistics, optimization, integration, linear algebra, Fourier transforms, signal and image processing, ODE solvers, and more.
This release candidate release comes one and a half year after the 0.7.0 release and contains many new features, numerous bug-fixes, improved test coverage, and better documentation. Please note that SciPy 0.8.0rc3 requires Python 2.4-2.6 and NumPy 1.4.1 or greater.
For more information, please see the release notes: http://sourceforge.net/projects/scipy/files/scipy/0.8.0rc3/NOTES.txt/view
You can download the release from here: https://sourceforge.net/projects/scipy/ Python 2.5/2.6 binaries for Windows and OS X are available, as well as source tarballs for other platforms and the documentation in pdf form.
Thank you to everybody who contributed to this release.
Enjoy, Ralf _______________________________________________ SciPy-User mailing list SciPy-User@scipy.org http://mail.scipy.org/mailman/listinfo/scipy-user
On 15.07.2010, at 11:15PM, Vincent Davis wrote:
Looks good for me now running py2.7 on oxs compiled 64bit
Ran 4407 tests in 119.221s OK (KNOWNFAIL=19, SKIP=35) <nose.result.TextTestResult run=4407 errors=0 failures=0>
Notably, I never got trouble-free builds with 2.7 - both the numpy and scipy test suites fail with a bus error - I already tried compiling with gcc 4.2 instead of 4.0, but to no avail. That said, numpy and scipy, as well as matplotlib and a number of other packages do run in everyday operations without any failures so far. With python2.5/2.6 I've found only two problems on MacOS X 10.5/PPC (already present in rc1 and rc2, sorry I did not get around to report them earlier): I. ====================================================================== ERROR: test_wavfile.test_read_1 ---------------------------------------------------------------------- Traceback (most recent call last): File "/sw/lib/python2.6/site-packages/nose/case.py", line 186, in runTest self.test(*self.arg) File "/sw/lib/python2.6/site-packages/scipy/io/tests/test_wavfile.py", line 14, in test_read_1 rate, data = wavfile.read(datafile('test-44100-le-1ch-4bytes.wav')) File "/sw/lib/python2.6/site-packages/scipy/io/wavfile.py", line 124, in read return rate, data UnboundLocalError: local variable 'data' referenced before assignment I noted there already is a fix for big-endian architectures in http://projects.scipy.org/scipy/changeset/5575 though I don't quite understand how it is supposed to work since _big_endian = False is still hardcoded. test-8000-le-2ch-1byteu.wav loads without errors anyway, but even when setting _big_endian = True manually, both files fail with a /sw/lib/python2.6/site-packages/scipy/io/wavfile.py in read(file) 119 else: 120 warnings.warn("chunk not understood", WavFileWarning) --> 121 size = struct.unpack('I',fid.read(4))[0] 122 bytes = fid.read(size) 123 fid.close() error: unpack requires a string argument of length 4 - sorry I can't be of more help with this. II. ====================================================================== FAIL: test_data.test_boost(<Data for gamma: test_gamma_data_ipp-near_m55>,) ---------------------------------------------------------------------- Traceback (most recent call last): File "/sw/lib/python2.6/site-packages/nose/case.py", line 186, in runTest self.test(*self.arg) File "/sw/lib/python2.6/site-packages/scipy/special/tests/test_data.py", line 205, in _test_factory test.check(dtype=dtype) File "/sw/lib/python2.6/site-packages/scipy/special/tests/testutils.py", line 223, in check assert False, "\n".join(msg) AssertionError: Max |adiff|: 5.56451e-80 Max |rdiff|: 6.01399e-12 Bad results for the following points (in output 0): -55.25 => 1.281342652143248e-73 != 1.2813426521356121e-73 (rdiff 5.9592794108831318e-12) -55.0625 => 9.8673260749254454e-73 != 9.8673260748719804e-73 (rdiff 5.4183854671083142e-12) -55.015625 => 4.736069454765531e-72 != 4.7360694547400013e-72 (rdiff 5.3904770710359471e-12) [remaining results skipped, all with 4.6e-12 < rdiff < 6.1e-12] I'd say just another case of too strict accuracy requirements. scipy.test('full') in addition produces the following failure on PPC: ====================================================================== FAIL: test_iv_cephes_vs_amos_mass_test (test_basic.TestBessel) ---------------------------------------------------------------------- Traceback (most recent call last): File "/sw/lib/python2.6/site-packages/scipy/special/tests/test_basic.py", line 1621, in test_iv_cephes_vs_amos_mass_test assert dc[k] < 1e-9, (v[k], x[k], iv(v[k], x[k]), iv(v[k], x[k]+0j)) AssertionError: (-1.685450377317264, 1.2676128629915242, 4.748141012443594e-05, (4.7481418802688318e-05+0j)) Both standard and full test pass on i386 and x86_64, but I noticed the following strange behaviour: when running the test suite twice in a row, the second run produces these failures: ====================================================================== FAIL: test_mio.test_mat4_3d(<type 'exceptions.DeprecationWarning'>, <functools.partial object at 0x33c66f0>, <StringIO.StringIO instance at 0x4d542b0>, {'a': array([[[ 0, 1, 2, 3], ---------------------------------------------------------------------- Traceback (most recent call last): File "/sw/lib/python2.6/site-packages/nose/case.py", line 186, in runTest self.test(*self.arg) File "/sw/lib/python2.6/site-packages/numpy/testing/utils.py", line 973, in assert_raises return nose.tools.assert_raises(*args,**kwargs) AssertionError: DeprecationWarning not raised ====================================================================== FAIL: test_00_deprecation_warning (test_basic.TestSolveHBanded) ---------------------------------------------------------------------- Traceback (most recent call last): File "/sw/lib/python2.6/site-packages/scipy/linalg/tests/test_basic.py", line 261, in test_00_deprecation_warning assert_raises(DeprecationWarning, solveh_banded, ab, b) File "/sw/lib/python2.6/site-packages/numpy/testing/utils.py", line 973, in assert_raises return nose.tools.assert_raises(*args,**kwargs) AssertionError: DeprecationWarning not raised ====================================================================== FAIL: Regression test for #651: better handling of badly conditioned ---------------------------------------------------------------------- Traceback (most recent call last): File "/sw/lib/python2.6/site-packages/scipy/signal/tests/test_filter_design.py", line 34, in test_bad_filter raise AssertionError("tf2zpk did not warn about bad "\ AssertionError: tf2zpk did not warn about bad coefficients Cheers, Derek
On Sat, Jul 17, 2010 at 4:50 AM, Derek Homeier < derek@astro.physik.uni-goettingen.de> wrote:
On 15.07.2010, at 11:15PM, Vincent Davis wrote:
Looks good for me now running py2.7 on oxs compiled 64bit
Ran 4407 tests in 119.221s OK (KNOWNFAIL=19, SKIP=35) <nose.result.TextTestResult run=4407 errors=0 failures=0>
Notably, I never got trouble-free builds with 2.7 - both the numpy and scipy test suites fail with a bus error - I already tried compiling with gcc 4.2 instead of 4.0, but to no avail.
Yes, there are issues with 2.7. Compiling against numpy 1.4.1 doesn't work, against trunk also has some issues on OS X. As Vincent pointed out, with a 64-bit Python 2.7 built with gcc-4.2 (python.org binaries are gcc-4.0) it does work without problems.
That said, numpy and scipy, as well as matplotlib and a number of other packages do run in everyday operations without any failures so far.
With python2.5/2.6 I've found only two problems on MacOS X 10.5/PPC (already present in rc1 and rc2, sorry I did not get around to report them earlier):
I. ====================================================================== ERROR: test_wavfile.test_read_1 ---------------------------------------------------------------------- Traceback (most recent call last): File "/sw/lib/python2.6/site-packages/nose/case.py", line 186, in runTest self.test(*self.arg) File "/sw/lib/python2.6/site-packages/scipy/io/tests/test_wavfile.py", line 14, in test_read_1 rate, data = wavfile.read(datafile('test-44100-le-1ch-4bytes.wav')) File "/sw/lib/python2.6/site-packages/scipy/io/wavfile.py", line 124, in read return rate, data UnboundLocalError: local variable 'data' referenced before assignment
I noted there already is a fix for big-endian architectures in http://projects.scipy.org/scipy/changeset/5575
though I don't quite understand how it is supposed to work since _big_endian = False is still hardcoded.
Further down _big_endian is declared as global, so not as hardcoded as it looks. But I don't think it ever worked, and that changeset didn't have tests: http://projects.scipy.org/scipy/ticket/873 I asked on the list a while ago if someone had time to fix this, but got no response. And since it's not a regression I'm afraid it'll have to wait till the next release.
test-8000-le-2ch-1byteu.wav loads without errors anyway, but even when setting _big_endian = True manually, both files fail with a /sw/lib/python2.6/site-packages/scipy/io/wavfile.py in read(file) 119 else: 120 warnings.warn("chunk not understood", WavFileWarning) --> 121 size = struct.unpack('I',fid.read(4))[0] 122 bytes = fid.read(size) 123 fid.close()
error: unpack requires a string argument of length 4
- sorry I can't be of more help with this.
II. ====================================================================== FAIL: test_data.test_boost(<Data for gamma: test_gamma_data_ipp-near_m55>,) ---------------------------------------------------------------------- Traceback (most recent call last): File "/sw/lib/python2.6/site-packages/nose/case.py", line 186, in runTest self.test(*self.arg) File "/sw/lib/python2.6/site-packages/scipy/special/tests/test_data.py", line 205, in _test_factory test.check(dtype=dtype) File "/sw/lib/python2.6/site-packages/scipy/special/tests/testutils.py", line 223, in check assert False, "\n".join(msg) AssertionError: Max |adiff|: 5.56451e-80 Max |rdiff|: 6.01399e-12 Bad results for the following points (in output 0): -55.25 => 1.281342652143248e-73 != 1.2813426521356121e-73 (rdiff 5.9592794108831318e-12) -55.0625 => 9.8673260749254454e-73 != 9.8673260748719804e-73 (rdiff 5.4183854671083142e-12) -55.015625 => 4.736069454765531e-72 != 4.7360694547400013e-72 (rdiff 5.3904770710359471e-12)
[remaining results skipped, all with 4.6e-12 < rdiff < 6.1e-12] I'd say just another case of too strict accuracy requirements.
These should have been fixed by r6520: - self.check_cephes_vs_amos(iv, iv, rtol=1e-12, atol=1e-305) + self.check_cephes_vs_amos(iv, iv, rtol=5e-9, atol=1e-305) data(gammaincinv, 'gamma_inv_big_data_ipp-gamma_inv_big_data', - (0,1), 2, rtol=5e-12), + (0,1), 2, rtol=1e-11), Can you check if you have these changes, and with what accuracy the tests pass? scipy.test('full') in addition produces the following failure on PPC:
====================================================================== FAIL: test_iv_cephes_vs_amos_mass_test (test_basic.TestBessel) ---------------------------------------------------------------------- Traceback (most recent call last): File "/sw/lib/python2.6/site-packages/scipy/special/tests/test_basic.py", line 1621, in test_iv_cephes_vs_amos_mass_test assert dc[k] < 1e-9, (v[k], x[k], iv(v[k], x[k]), iv(v[k], x[k]+0j)) AssertionError: (-1.685450377317264, 1.2676128629915242, 4.748141012443594e-05, (4.7481418802688318e-05+0j))
Both standard and full test pass on i386 and x86_64, but I noticed the following strange behaviour: when running the test suite twice in a row, the second run produces these failures:
This is because warnings are only raised once from the same code, so the check if they're raised a second time fails. So no problem. Cheers, Ralf
====================================================================== FAIL: test_mio.test_mat4_3d(<type 'exceptions.DeprecationWarning'>, <functools.partial object at 0x33c66f0>, <StringIO.StringIO instance at 0x4d542b0>, {'a': array([[[ 0, 1, 2, 3], ---------------------------------------------------------------------- Traceback (most recent call last): File "/sw/lib/python2.6/site-packages/nose/case.py", line 186, in runTest self.test(*self.arg) File "/sw/lib/python2.6/site-packages/numpy/testing/utils.py", line 973, in assert_raises return nose.tools.assert_raises(*args,**kwargs) AssertionError: DeprecationWarning not raised
====================================================================== FAIL: test_00_deprecation_warning (test_basic.TestSolveHBanded) ---------------------------------------------------------------------- Traceback (most recent call last): File "/sw/lib/python2.6/site-packages/scipy/linalg/tests/test_basic.py", line 261, in test_00_deprecation_warning assert_raises(DeprecationWarning, solveh_banded, ab, b) File "/sw/lib/python2.6/site-packages/numpy/testing/utils.py", line 973, in assert_raises return nose.tools.assert_raises(*args,**kwargs) AssertionError: DeprecationWarning not raised
====================================================================== FAIL: Regression test for #651: better handling of badly conditioned ---------------------------------------------------------------------- Traceback (most recent call last): File "/sw/lib/python2.6/site-packages/scipy/signal/tests/test_filter_design.py", line 34, in test_bad_filter raise AssertionError("tf2zpk did not warn about bad "\ AssertionError: tf2zpk did not warn about bad coefficients
Cheers, Derek
_______________________________________________ SciPy-Dev mailing list SciPy-Dev@scipy.org http://mail.scipy.org/mailman/listinfo/scipy-dev
Hi Ralf,
Notably, I never got trouble-free builds with 2.7 - both the numpy and scipy test suites fail with a bus error - I already tried compiling with gcc 4.2 instead of 4.0, but to no avail.
Yes, there are issues with 2.7. Compiling against numpy 1.4.1 doesn't work, against trunk also has some issues on OS X. As Vincent pointed out, with a 64-bit Python 2.7 built with gcc-4.2 (python.org binaries are gcc-4.0) it does work without problems.
well, as I said I did try the gcc-4.2 build, but probably missed that Vincent was compiling numpy trunk - I probably should try again on my 10.6 64-bit installation. Anyway, compiling both numpy 1.4.1 and scipy 0.8.0rc3 works fine both on i386/ppc 32-bit and and x86_64, using the fink build system. And it is running as well, so far, except for those tests - btw. numpy.test(verbose=5) crashes at test_multiarray.TestIO.test_ascii ... Bus error and scipy.test() at Testing that kmeans2 init methods work. ... Bus error
These should have been fixed by r6520: - self.check_cephes_vs_amos(iv, iv, rtol=1e-12, atol=1e-305) + self.check_cephes_vs_amos(iv, iv, rtol=5e-9, atol=1e-305)
data(gammaincinv, 'gamma_inv_big_data_ipp- gamma_inv_big_data', - (0,1), 2, rtol=5e-12), + (0,1), 2, rtol=1e-11),
Can you check if you have these changes, and with what accuracy the tests pass?
I have (rc3 tarball), but it's a different couple of tests. 'gamma_inv_big_data_ipp-gamma_inv_big_data' actually still passes with rtol=2.1e-12. These are the minimal accuracy changes needed: --- /sw/lib/python2.6/site-packages/scipy/special/tests/test_data.py 2010-07-11 17:25:24.000000000 +0200 +++ test_data.py 2010-07-17 21:13:07.000000000 +0200 @@ -85,7 +85,7 @@ data(gamma, 'test_gamma_data_ipp-near_1', 0, 1), data(gamma, 'test_gamma_data_ipp-near_2', 0, 1), data(gamma, 'test_gamma_data_ipp-near_m10', 0, 1), - data(gamma, 'test_gamma_data_ipp-near_m55', 0, 1), + data(gamma, 'test_gamma_data_ipp-near_m55', 0, 1, rtol=7e-12), data(gamma, 'test_gamma_data_ipp-near_0', 0j, 1, rtol=2e-9), data(gamma, 'test_gamma_data_ipp-near_1', 0j, 1, rtol=2e-9), data(gamma, 'test_gamma_data_ipp-near_2', 0j, 1, rtol=2e-9), --- /sw/lib/python2.6/site-packages/scipy/special/tests/test_basic.py 2010-07-11 17:25:24.000000000 +0200 +++ test_basic.py 2010-07-17 21:28:07.000000000 +0200 @@ -1618,7 +1618,7 @@ # Most error apparently comes from AMOS and not our implementation; # there are some problems near integer orders there - assert dc[k] < 1e-9, (v[k], x[k], iv(v[k], x[k]), iv(v[k], x[k]+0j)) + assert dc[k] < 1.9e-7, (v[k], x[k], iv(v[k], x[k]), iv(v[k], x[k]+0j)) def test_kv_cephes_vs_amos(self): #self.check_cephes_vs_amos(kv, kn, rtol=1e-9, atol=1e-305) Of course nearly 2e-7 seems a quite high tolerance - don't know if that's acceptable.
Both standard and full test pass on i386 and x86_64, but I noticed the following strange behaviour: when running the test suite twice in a row, the second run produces these failures:
This is because warnings are only raised once from the same code, so the check if they're raised a second time fails. So no problem.
Ah, that makes sense, thanks! Cheers, Derek
On Sat, Jul 17, 2010 at 4:30 PM, Derek Homeier <derek@astro.physik.uni-goettingen.de> wrote:
Hi Ralf,
Notably, I never got trouble-free builds with 2.7 - both the numpy and scipy test suites fail with a bus error - I already tried compiling with gcc 4.2 instead of 4.0, but to no avail.
Yes, there are issues with 2.7. Compiling against numpy 1.4.1 doesn't work, against trunk also has some issues on OS X. As Vincent pointed out, with a 64-bit Python 2.7 built with gcc-4.2 (python.org binaries are gcc-4.0) it does work without problems.
well, as I said I did try the gcc-4.2 build, but probably missed that Vincent was compiling numpy trunk - I probably should try again on my 10.6 64-bit installation. For you information Python version 2.7.0+ (release27-maint:82653, Jul 8 2010, 14:45:18) [GCC 4.2.1 (Apple Inc. build 5659)]
Build commands used python 2.7 ./configure --with-universal-archs=64-bit --enable-universalsdk=/Developer/SDKs/MacOSX10.5.sdk --enable-framework for numpy and scipy I used LDFLAGS="-arch x86_64" FFLAGS="-arch x86_64" py27 setupscons.py scons Vincent
Anyway, compiling both numpy 1.4.1 and scipy 0.8.0rc3 works fine both on i386/ppc 32-bit and and x86_64, using the fink build system. And it is running as well, so far, except for those tests - btw. numpy.test(verbose=5) crashes at test_multiarray.TestIO.test_ascii ... Bus error
and scipy.test() at Testing that kmeans2 init methods work. ... Bus error
These should have been fixed by r6520: - self.check_cephes_vs_amos(iv, iv, rtol=1e-12, atol=1e-305) + self.check_cephes_vs_amos(iv, iv, rtol=5e-9, atol=1e-305)
data(gammaincinv, 'gamma_inv_big_data_ipp- gamma_inv_big_data', - (0,1), 2, rtol=5e-12), + (0,1), 2, rtol=1e-11),
Can you check if you have these changes, and with what accuracy the tests pass?
I have (rc3 tarball), but it's a different couple of tests. 'gamma_inv_big_data_ipp-gamma_inv_big_data' actually still passes with rtol=2.1e-12.
These are the minimal accuracy changes needed:
--- /sw/lib/python2.6/site-packages/scipy/special/tests/test_data.py 2010-07-11 17:25:24.000000000 +0200 +++ test_data.py 2010-07-17 21:13:07.000000000 +0200 @@ -85,7 +85,7 @@ data(gamma, 'test_gamma_data_ipp-near_1', 0, 1), data(gamma, 'test_gamma_data_ipp-near_2', 0, 1), data(gamma, 'test_gamma_data_ipp-near_m10', 0, 1), - data(gamma, 'test_gamma_data_ipp-near_m55', 0, 1), + data(gamma, 'test_gamma_data_ipp-near_m55', 0, 1, rtol=7e-12), data(gamma, 'test_gamma_data_ipp-near_0', 0j, 1, rtol=2e-9), data(gamma, 'test_gamma_data_ipp-near_1', 0j, 1, rtol=2e-9), data(gamma, 'test_gamma_data_ipp-near_2', 0j, 1, rtol=2e-9), --- /sw/lib/python2.6/site-packages/scipy/special/tests/test_basic.py 2010-07-11 17:25:24.000000000 +0200 +++ test_basic.py 2010-07-17 21:28:07.000000000 +0200 @@ -1618,7 +1618,7 @@
# Most error apparently comes from AMOS and not our implementation; # there are some problems near integer orders there - assert dc[k] < 1e-9, (v[k], x[k], iv(v[k], x[k]), iv(v[k], x[k]+0j)) + assert dc[k] < 1.9e-7, (v[k], x[k], iv(v[k], x[k]), iv(v[k], x[k]+0j))
def test_kv_cephes_vs_amos(self): #self.check_cephes_vs_amos(kv, kn, rtol=1e-9, atol=1e-305)
Of course nearly 2e-7 seems a quite high tolerance - don't know if that's acceptable.
Both standard and full test pass on i386 and x86_64, but I noticed the following strange behaviour: when running the test suite twice in a row, the second run produces these failures:
This is because warnings are only raised once from the same code, so the check if they're raised a second time fails. So no problem.
Ah, that makes sense, thanks!
Cheers, Derek
_______________________________________________ SciPy-Dev mailing list SciPy-Dev@scipy.org http://mail.scipy.org/mailman/listinfo/scipy-dev
On 18.07.2010, at 12:44AM, Vincent Davis wrote:
well, as I said I did try the gcc-4.2 build, but probably missed that Vincent was compiling numpy trunk - I probably should try again on my 10.6 64-bit installation. For you information Python version 2.7.0+ (release27-maint:82653, Jul 8 2010, 14:45:18) [GCC 4.2.1 (Apple Inc. build 5659)]
Build commands used python 2.7 ./configure --with-universal-archs=64-bit --enable-universalsdk=/Developer/SDKs/MacOSX10.5.sdk --enable-framework
for numpy and scipy I used LDFLAGS="-arch x86_64" FFLAGS="-arch x86_64" py27 setupscons.py scons
thanks for the pointer, but the crucial point was in fact, as Ralf mentioned, using the numpy-1.4.1 release - after I upgraded to numpy-2.0.0.dev8509 from svn, both numpy and scipy tests passed simply building with the defaults (which amount to 64bit compile on my OS X 10.6 installation anyway, I believe). Cheers, Derek
On Sun, Jul 18, 2010 at 6:30 AM, Derek Homeier < derek@astro.physik.uni-goettingen.de> wrote:
These should have been fixed by r6520: - self.check_cephes_vs_amos(iv, iv, rtol=1e-12, atol=1e-305) + self.check_cephes_vs_amos(iv, iv, rtol=5e-9, atol=1e-305)
data(gammaincinv, 'gamma_inv_big_data_ipp- gamma_inv_big_data', - (0,1), 2, rtol=5e-12), + (0,1), 2, rtol=1e-11),
Can you check if you have these changes, and with what accuracy the tests pass?
I have (rc3 tarball), but it's a different couple of tests. 'gamma_inv_big_data_ipp-gamma_inv_big_data' actually still passes with rtol=2.1e-12.
These are the minimal accuracy changes needed:
--- /sw/lib/python2.6/site-packages/scipy/special/tests/test_data.py 2010-07-11 17:25:24.000000000 +0200 +++ test_data.py 2010-07-17 21:13:07.000000000 +0200 @@ -85,7 +85,7 @@ data(gamma, 'test_gamma_data_ipp-near_1', 0, 1), data(gamma, 'test_gamma_data_ipp-near_2', 0, 1), data(gamma, 'test_gamma_data_ipp-near_m10', 0, 1), - data(gamma, 'test_gamma_data_ipp-near_m55', 0, 1), + data(gamma, 'test_gamma_data_ipp-near_m55', 0, 1, rtol=7e-12), data(gamma, 'test_gamma_data_ipp-near_0', 0j, 1, rtol=2e-9), data(gamma, 'test_gamma_data_ipp-near_1', 0j, 1, rtol=2e-9), data(gamma, 'test_gamma_data_ipp-near_2', 0j, 1, rtol=2e-9), --- /sw/lib/python2.6/site-packages/scipy/special/tests/test_basic.py 2010-07-11 17:25:24.000000000 +0200 +++ test_basic.py 2010-07-17 21:28:07.000000000 +0200 @@ -1618,7 +1618,7 @@
# Most error apparently comes from AMOS and not our implementation; # there are some problems near integer orders there - assert dc[k] < 1e-9, (v[k], x[k], iv(v[k], x[k]), iv(v[k], x[k]+0j)) + assert dc[k] < 1.9e-7, (v[k], x[k], iv(v[k], x[k]), iv(v[k], x[k]+0j))
def test_kv_cephes_vs_amos(self): #self.check_cephes_vs_amos(kv, kn, rtol=1e-9, atol=1e-305)
Of course nearly 2e-7 seems a quite high tolerance - don't know if that's acceptable.
That does seem a little high. I guess Pauli has to decide whether this qualifies as a bug or not.
Cheers, Ralf
Sun, 18 Jul 2010 22:22:43 +0800, Ralf Gommers wrote: [clip]
assert dc[k] < 1e-9, (v[k], x[k], iv(v[k], x[k]), iv(v[k], x[k]+0j)) AssertionError: (-1.685450377317264, 1.2676128629915242, 4.748141012443594e-05, (4.7481418802688318e-05+0j))
relative error <~ 2e-7
That does seem a little high. I guess Pauli has to decide whether this qualifies as a bug or not.
Works for me. No idea how to fix this, since it probably is compiler specific. On the other hand, that's pretty close to a zero of Iv, where there is cancellation error (since v < 0 we use a reflection identity), so it's probably a difficult spot anyway. Maybe the treshold could be made platform-dependent -- I wouldn't like to bump it if it fails only on a single platform/compiler combination. Pauli
Looks good on Ubuntu Lucid 64 bit, py2.6, self-built numpy 1.4.1: Ran 4407 tests in Ran 4407 tests in 59.976s OK (KNOWNFAIL=13, SKIP=34) <nose.result.TextTestResult run=4407 errors=0 failures=0> On 15/07/10 18:27, Ralf Gommers wrote:
I'm pleased to announce the availability of the third release candidate of SciPy 0.8.0. The only changes compared to rc2 are a fix for a regression in interpolate.Rbf and some fixes for failures on 64-bit Windows. If no more problems are reported, the final release will be available in one week.
SciPy is a package of tools for science and engineering for Python. It includes modules for statistics, optimization, integration, linear algebra, Fourier transforms, signal and image processing, ODE solvers, and more.
This release candidate release comes one and a half year after the 0.7.0 release and contains many new features, numerous bug-fixes, improved test coverage, and better documentation. Please note that SciPy 0.8.0rc3 requires Python 2.4-2.6 and NumPy 1.4.1 or greater.
For more information, please see the release notes: http://sourceforge.net/projects/scipy/files/scipy/0.8.0rc3/NOTES.txt/view <http://sourceforge.net/projects/scipy/files/scipy/0.8.0rc1/NOTES.txt/view>
You can download the release from here: https://sourceforge.net/projects/scipy/ Python 2.5/2.6 binaries for Windows and OS X are available, as well as source tarballs for other platforms and the documentation in pdf form.
Thank you to everybody who contributed to this release.
Enjoy, Ralf
_______________________________________________ SciPy-Dev mailing list SciPy-Dev@scipy.org http://mail.scipy.org/mailman/listinfo/scipy-dev
participants (5)
-
Derek Homeier -
Pauli Virtanen -
Ralf Gommers -
Vincent Davis -
Yosef Meller