Re: [Numpy-discussion] scipy 0.7.1rc2 released
2009/6/8 Matthieu Brucher matthieu.bruc...@gmail.com: I'm trying to compile it with ICC 10.1.018, and it fails :| icc: scipy/special/cephes/const.c scipy/special/cephes/const.c(94): error: floating-point operation result is out of range double INFINITY = 1.0/0.0; /* 99e999; */ ^ scipy/special/cephes/const.c(99): error: floating-point operation result is out of range double NAN = 1.0/0.0 - 1.0/0.0; ^ scipy/special/cephes/const.c(99): error: floating-point operation result is out of range double NAN = 1.0/0.0 - 1.0/0.0; ^ compilation aborted for scipy/special/cephes/const.c (code 2) scipy/special/cephes/const.c(94): error: floating-point operation result is out of range double INFINITY = 1.0/0.0; /* 99e999; */ ^ scipy/special/cephes/const.c(99): error: floating-point operation result is out of range double NAN = 1.0/0.0 - 1.0/0.0; ^ scipy/special/cephes/const.c(99): error: floating-point operation result is out of range double NAN = 1.0/0.0 - 1.0/0.0; At least, it seems to pick up the Fortran compiler correctly (which 0.7.0 didn't seem to do ;)) I manually fixed the files (mconf.h as well as ync.c which uses NAN, which can be not imported if NANS is defined, which is the case here for ICC), but I ran into an another error (one of the reason I tried numscons before): /appli/intel/10.1.018/intel64/fce/bin/ifort -shared -shared -nofor_main build/temp.linux-x86_64-2.5/build/src.linux-x86_64-2.5/scipy/fftpack/_fftpackmodule.o build/temp.linux-x86_64-2.5/scipy/fftpack/src/zfft.o build/temp.linux-x86_64-2.5/scipy/fftpack/src/drfft.o build/temp.linux-x86_64-2.5/scipy/fftpack/src/zrfft.o build/temp.linux-x86_64-2.5/scipy/fftpack/src/zfftnd.o build/temp.linux-x86_64-2.5/build/src.linux-x86_64-2.5/fortranobject.o -Lbuild/temp.linux-x86_64-2.5 -ldfftpack -o build/lib.linux-x86_64-2.5/scipy/fftpack/_fftpack.so ld: build/temp.linux-x86_64-2.5/libdfftpack.a(dffti1.o): relocation R_X86_64_32S against `a local symbol' can not be used when making a shared object; recompile with -fPIC build/temp.linux-x86_64-2.5/libdfftpack.a: could not read symbols: Bad value ld: build/temp.linux-x86_64-2.5/libdfftpack.a(dffti1.o): relocation R_X86_64_32S against `a local symbol' can not be used when making a shared object; recompile with -fPIC build/temp.linux-x86_64-2.5/libdfftpack.a: could not read symbols: Bad value It seems that the library is not compiled with fPIC (perhaps because it is a static library?). My compiler options are: Fortran f77 compiler: ifort -FI -w90 -w95 -xW -axP -O3 -unroll Fortran f90 compiler: ifort -FR -xW -axP -O3 -unroll Fortran fix compiler: ifort -FI -xW -axP -O3 -unroll Matthieu -- Information System Engineer, Ph.D. Website: http://matthieu-brucher.developpez.com/ Blogs: http://matt.eifelle.com and http://blog.developpez.com/?blog=92 LinkedIn: http://www.linkedin.com/in/matthieubrucher ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] scipy 0.7.1rc2 released
I'm trying to compile it with ICC 10.1.018, and it fails :| icc: scipy/special/cephes/const.c scipy/special/cephes/const.c(94): error: floating-point operation result is out of range double INFINITY = 1.0/0.0; /* 99e999; */ ^ scipy/special/cephes/const.c(99): error: floating-point operation result is out of range double NAN = 1.0/0.0 - 1.0/0.0; ^ scipy/special/cephes/const.c(99): error: floating-point operation result is out of range double NAN = 1.0/0.0 - 1.0/0.0; ^ compilation aborted for scipy/special/cephes/const.c (code 2) scipy/special/cephes/const.c(94): error: floating-point operation result is out of range double INFINITY = 1.0/0.0; /* 99e999; */ ^ scipy/special/cephes/const.c(99): error: floating-point operation result is out of range double NAN = 1.0/0.0 - 1.0/0.0; ^ scipy/special/cephes/const.c(99): error: floating-point operation result is out of range double NAN = 1.0/0.0 - 1.0/0.0; At least, it seems to pick up the Fortran compiler correctly (which 0.7.0 didn't seem to do ;)) Matthieu 2009/6/7 Adam Mercer ramer...@gmail.com: On Fri, Jun 5, 2009 at 06:09, David Cournapeaucourn...@gmail.com wrote: Please test it ! I am particularly interested in results for scipy binaries on mac os x (do they work on ppc). Test suite passes on Intel Mac OS X (10.5.7) built from source: OK (KNOWNFAIL=6, SKIP=21) nose.result.TextTestResult run=3486 errors=0 failures=0 Cheers Adam ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion -- Information System Engineer, Ph.D. Website: http://matthieu-brucher.developpez.com/ Blogs: http://matt.eifelle.com and http://blog.developpez.com/?blog=92 LinkedIn: http://www.linkedin.com/in/matthieubrucher ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] scipy 0.7.1rc2 released
Matthieu Brucher wrote: I'm trying to compile it with ICC 10.1.018, and it fails :| icc: scipy/special/cephes/const.c scipy/special/cephes/const.c(94): error: floating-point operation result is out of range double INFINITY = 1.0/0.0; /* 99e999; */ ^ scipy/special/cephes/const.c(99): error: floating-point operation result is out of range double NAN = 1.0/0.0 - 1.0/0.0; ^ scipy/special/cephes/const.c(99): error: floating-point operation result is out of range double NAN = 1.0/0.0 - 1.0/0.0; ^ compilation aborted for scipy/special/cephes/const.c (code 2) scipy/special/cephes/const.c(94): error: floating-point operation result is out of range double INFINITY = 1.0/0.0; /* 99e999; */ ^ scipy/special/cephes/const.c(99): error: floating-point operation result is out of range double NAN = 1.0/0.0 - 1.0/0.0; ^ scipy/special/cephes/const.c(99): error: floating-point operation result is out of range double NAN = 1.0/0.0 - 1.0/0.0; At least, it seems to pick up the Fortran compiler correctly (which 0.7.0 didn't seem to do ;)) This code makes me cry... I know Visual Studio won't like it either. Cephes is a constant source of problems . As I mentioned a couple of months ago, I think the only solution is to rewrite most of scipy.special, at least the parts using cephes, using for example boost algorithms and unit tests. But I have not started anything concrete - Pauli did most of the work on scipy.special recently (Kudos to Pauli for consistently improving scipy.special, BTW) cheers, David ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] scipy 0.7.1rc2 released
2009/6/8 David Cournapeau da...@ar.media.kyoto-u.ac.jp: Matthieu Brucher wrote: I'm trying to compile it with ICC 10.1.018, and it fails :| icc: scipy/special/cephes/const.c scipy/special/cephes/const.c(94): error: floating-point operation result is out of range double INFINITY = 1.0/0.0; /* 99e999; */ ^ scipy/special/cephes/const.c(99): error: floating-point operation result is out of range double NAN = 1.0/0.0 - 1.0/0.0; ^ scipy/special/cephes/const.c(99): error: floating-point operation result is out of range double NAN = 1.0/0.0 - 1.0/0.0; ^ compilation aborted for scipy/special/cephes/const.c (code 2) scipy/special/cephes/const.c(94): error: floating-point operation result is out of range double INFINITY = 1.0/0.0; /* 99e999; */ ^ scipy/special/cephes/const.c(99): error: floating-point operation result is out of range double NAN = 1.0/0.0 - 1.0/0.0; ^ scipy/special/cephes/const.c(99): error: floating-point operation result is out of range double NAN = 1.0/0.0 - 1.0/0.0; At least, it seems to pick up the Fortran compiler correctly (which 0.7.0 didn't seem to do ;)) This code makes me cry... I know Visual Studio won't like it either. Cephes is a constant source of problems . As I mentioned a couple of months ago, I think the only solution is to rewrite most of scipy.special, at least the parts using cephes, using for example boost algorithms and unit tests. But I have not started anything concrete - Pauli did most of the work on scipy.special recently (Kudos to Pauli for consistently improving scipy.special, BTW) cheers, It could be simply enhanced by refactoring only mconf.h with proper compiler flags, and fix yn.c to remove the NAN detection (as it should be in the mconf.h). Unfortunately, I have no time for this at the moment (besides the fact that it is on my workstation, not at home). Matthieu -- Information System Engineer, Ph.D. Website: http://matthieu-brucher.developpez.com/ Blogs: http://matt.eifelle.com and http://blog.developpez.com/?blog=92 LinkedIn: http://www.linkedin.com/in/matthieubrucher ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] scipy 0.7.1rc2 released
On Mon, Jun 8, 2009 at 8:45 PM, Matthieu Bruchermatthieu.bruc...@gmail.com wrote: 2009/6/8 David Cournapeau da...@ar.media.kyoto-u.ac.jp: Matthieu Brucher wrote: I'm trying to compile it with ICC 10.1.018, and it fails :| icc: scipy/special/cephes/const.c scipy/special/cephes/const.c(94): error: floating-point operation result is out of range double INFINITY = 1.0/0.0; /* 99e999; */ ^ scipy/special/cephes/const.c(99): error: floating-point operation result is out of range double NAN = 1.0/0.0 - 1.0/0.0; ^ scipy/special/cephes/const.c(99): error: floating-point operation result is out of range double NAN = 1.0/0.0 - 1.0/0.0; ^ compilation aborted for scipy/special/cephes/const.c (code 2) scipy/special/cephes/const.c(94): error: floating-point operation result is out of range double INFINITY = 1.0/0.0; /* 99e999; */ ^ scipy/special/cephes/const.c(99): error: floating-point operation result is out of range double NAN = 1.0/0.0 - 1.0/0.0; ^ scipy/special/cephes/const.c(99): error: floating-point operation result is out of range double NAN = 1.0/0.0 - 1.0/0.0; At least, it seems to pick up the Fortran compiler correctly (which 0.7.0 didn't seem to do ;)) This code makes me cry... I know Visual Studio won't like it either. Cephes is a constant source of problems . As I mentioned a couple of months ago, I think the only solution is to rewrite most of scipy.special, at least the parts using cephes, using for example boost algorithms and unit tests. But I have not started anything concrete - Pauli did most of the work on scipy.special recently (Kudos to Pauli for consistently improving scipy.special, BTW) cheers, It could be simply enhanced by refactoring only mconf.h with proper compiler flags, and fix yn.c to remove the NAN detection (as it should be in the mconf.h). NAN and co definition should be dealt with the portable definitions we have now in numpy - I just have to find a way to reuse the corresponding code outside numpy (distutils currently does not handle proper installation of libraries built through build_clib), it is on my TODO list for scipy 0.8. Unfortunately, this is only the tip of the iceberg. A lot of code in cephes uses #ifdef on platform specificities, and let's not forget it is pre-ANSI C code (KR declarations), with a lot of hidden bugs.\ cheers, David ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] scipy 0.7.1rc2 released
Good luck with fixing this then :| I've tried to build scipy with the MKL and ATLAS, and I have in both cases a segmentation fault. With the MKL, it is the same as in a previous mail, and for ATLAS it is there: Regression test for #946. ... Segmentation fault A bad ATLAS compilation? Matthieu It could be simply enhanced by refactoring only mconf.h with proper compiler flags, and fix yn.c to remove the NAN detection (as it should be in the mconf.h). NAN and co definition should be dealt with the portable definitions we have now in numpy - I just have to find a way to reuse the corresponding code outside numpy (distutils currently does not handle proper installation of libraries built through build_clib), it is on my TODO list for scipy 0.8. Unfortunately, this is only the tip of the iceberg. A lot of code in cephes uses #ifdef on platform specificities, and let's not forget it is pre-ANSI C code (KR declarations), with a lot of hidden bugs.\ cheers, David ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion -- Information System Engineer, Ph.D. Website: http://matthieu-brucher.developpez.com/ Blogs: http://matt.eifelle.com and http://blog.developpez.com/?blog=92 LinkedIn: http://www.linkedin.com/in/matthieubrucher ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] scipy 0.7.1rc2 released
2009/6/8 David Cournapeau da...@ar.media.kyoto-u.ac.jp: Matthieu Brucher wrote: Good luck with fixing this then :| I've tried to build scipy with the MKL and ATLAS, and I have in both cases a segmentation fault. With the MKL, it is the same as in a previous mail, and for ATLAS it is there: Regression test for #946. ... Segmentation fault Could you try the last revision in the 0.7.x branch ? There were quite a few problems with this exact code (that's the only reason why scipy 0.7.1 is not released yet, actually), and I added an ugly workaround for the time being, but that should work, David Is there a way to get a tarball from the repository on the webpage? I can't do a checkout (no TortoiseSVN installed on my Windows and no web access from Linux :() Matthieu -- Information System Engineer, Ph.D. Website: http://matthieu-brucher.developpez.com/ Blogs: http://matt.eifelle.com and http://blog.developpez.com/?blog=92 LinkedIn: http://www.linkedin.com/in/matthieubrucher ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] scipy 0.7.1rc2 released
OK, I'm stuck with #946 with the MKL as well (finally managed to compile and use it with only the static library safe for libguide). I'm trying to download the trunk at the moment to check if the segmentation fault is still there. Matthieu 2009/6/8 Matthieu Brucher matthieu.bruc...@gmail.com: Good luck with fixing this then :| I've tried to build scipy with the MKL and ATLAS, and I have in both cases a segmentation fault. With the MKL, it is the same as in a previous mail, and for ATLAS it is there: Regression test for #946. ... Segmentation fault A bad ATLAS compilation? Matthieu It could be simply enhanced by refactoring only mconf.h with proper compiler flags, and fix yn.c to remove the NAN detection (as it should be in the mconf.h). NAN and co definition should be dealt with the portable definitions we have now in numpy - I just have to find a way to reuse the corresponding code outside numpy (distutils currently does not handle proper installation of libraries built through build_clib), it is on my TODO list for scipy 0.8. Unfortunately, this is only the tip of the iceberg. A lot of code in cephes uses #ifdef on platform specificities, and let's not forget it is pre-ANSI C code (KR declarations), with a lot of hidden bugs.\ cheers, David ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion -- Information System Engineer, Ph.D. Website: http://matthieu-brucher.developpez.com/ Blogs: http://matt.eifelle.com and http://blog.developpez.com/?blog=92 LinkedIn: http://www.linkedin.com/in/matthieubrucher -- Information System Engineer, Ph.D. Website: http://matthieu-brucher.developpez.com/ Blogs: http://matt.eifelle.com and http://blog.developpez.com/?blog=92 LinkedIn: http://www.linkedin.com/in/matthieubrucher ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] scipy 0.7.1rc2 released
David, I've checked out the trunk, and the segmentation fault isn't there anymore (the trunk is labeled 0.8.0 though) Here is the log from the remaining errors with the MKL: == ERROR: Failure: ImportError (/data/pau112/INNO/local/x86_64/lib/python2.5/site-packages/scipy/linalg/atlas_version.so: undefined symbol: ATL_buildinfo) -- Traceback (most recent call last): File /data/pau112/INNO/local/x86_64/lib/python2.5/site-packages/nose/loader.py, line 364, in loadTestsFromName addr.filename, addr.module) File /data/pau112/INNO/local/x86_64/lib/python2.5/site-packages/nose/importer.py, line 39, in importFromPath return self.importFromDir(dir_path, fqname) File /data/pau112/INNO/local/x86_64/lib/python2.5/site-packages/nose/importer.py, line 84, in importFromDir mod = load_module(part_fqname, fh, filename, desc) File /data/pau112/INNO/local/x86_64/lib/python2.5/site-packages/scipy/linalg/tests/test_atlas_version.py, line 8, in module import scipy.linalg.atlas_version ImportError: /data/pau112/INNO/local/x86_64/lib/python2.5/site-packages/scipy/linalg/atlas_version.so: undefined symbol: ATL_buildinfo == ERROR: test_io.test_imread -- Traceback (most recent call last): File /data/pau112/INNO/local/x86_64/lib/python2.5/site-packages/nose/case.py, line 182, in runTest self.test(*self.arg) File /data/pau112/INNO/local/x86_64/lib/python2.5/site-packages/scipy/ndimage/tests/test_io.py, line 8, in test_imread img = ndi.imread(lp) AttributeError: 'module' object has no attribute 'imread' == ERROR: test_outer_v (test_lgmres.TestLGMRES) -- Traceback (most recent call last): File /data/pau112/INNO/local/x86_64/lib/python2.5/site-packages/scipy/sparse/linalg/isolve/tests/test_lgmres.py, line 52, in test_outer_v x0, count_0 = do_solve(outer_k=6, outer_v=outer_v) File /data/pau112/INNO/local/x86_64/lib/python2.5/site-packages/scipy/sparse/linalg/isolve/tests/test_lgmres.py, line 29, in do_solve x0, flag = lgmres(A, b, x0=zeros(A.shape[0]), inner_m=6, tol=1e-14, **kw) TypeError: 'module' object is not callable == ERROR: test_preconditioner (test_lgmres.TestLGMRES) -- Traceback (most recent call last): File /data/pau112/INNO/local/x86_64/lib/python2.5/site-packages/scipy/sparse/linalg/isolve/tests/test_lgmres.py, line 41, in test_preconditioner x0, count_0 = do_solve() File /data/pau112/INNO/local/x86_64/lib/python2.5/site-packages/scipy/sparse/linalg/isolve/tests/test_lgmres.py, line 29, in do_solve x0, flag = lgmres(A, b, x0=zeros(A.shape[0]), inner_m=6, tol=1e-14, **kw) TypeError: 'module' object is not callable == ERROR: test_iv_cephes_vs_amos (test_basic.TestBessel) -- Traceback (most recent call last): File /data/pau112/INNO/local/x86_64/lib/python2.5/site-packages/scipy/special/tests/test_basic.py, line 1691, in test_iv_cephes_vs_amos self.check_cephes_vs_amos(iv, iv, rtol=1e-12, atol=1e-305) File /data/pau112/INNO/local/x86_64/lib/python2.5/site-packages/scipy/special/tests/test_basic.py, line 1672, in check_cephes_vs_amos assert_tol_equal(c1, c2, err_msg=(v, z), rtol=rtol, atol=atol) File /data/pau112/INNO/local/x86_64/lib/python2.5/site-packages/scipy/special/tests/test_basic.py, line 38, in assert_tol_equal verbose=verbose, header=header) File /data/pau112/INNO/local/x86_64/lib/python2.5/site-packages/numpy/testing/utils.py, line 377, in assert_array_compare val = comparison(x[~xnanid], y[~ynanid]) IndexError: 0-d arrays can't be indexed == FAIL: test_lorentz (test_odr.TestODR) -- Traceback (most recent call last): File /data/pau112/INNO/local/x86_64/lib/python2.5/site-packages/scipy/odr/tests/test_odr.py, line 292, in test_lorentz 3.7798193600109009e+00]), File /data/pau112/INNO/local/x86_64/lib/python2.5/site-packages/numpy/testing/utils.py, line 537, in assert_array_almost_equal header='Arrays are not almost equal') File /data/pau112/INNO/local/x86_64/lib/python2.5/site-packages/numpy/testing/utils.py, line 395, in assert_array_compare raise AssertionError(msg) AssertionError: Arrays are not almost equal (mismatch 100.0%) x: array([ 1.e+03, 1.e-01, 3.8000e+00])
Re: [Numpy-discussion] scipy 0.7.1rc2 released
Matthieu Brucher wrote: David, I've checked out the trunk, and the segmentation fault isn't there anymore (the trunk is labeled 0.8.0 though) Yes, the upcoming 0.7.1 release has its code in the 0.7.x svn branch. But the fix for #946 is a backport of 0.8.0, so in theory, it should be fixed :) Concerning the other errors: did you compile with intel compilers or GNU ones ? cheers, David ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] scipy 0.7.1rc2 released
2009/6/8 David Cournapeau da...@ar.media.kyoto-u.ac.jp: Matthieu Brucher wrote: David, I've checked out the trunk, and the segmentation fault isn't there anymore (the trunk is labeled 0.8.0 though) Yes, the upcoming 0.7.1 release has its code in the 0.7.x svn branch. But the fix for #946 is a backport of 0.8.0, so in theory, it should be fixed :) OK, I didn't check the branches, I should have :| Concerning the other errors: did you compile with intel compilers or GNU ones ? Only Intel compilers. Maybe I should check the rc branch instead of the trunk? Matthieu -- Information System Engineer, Ph.D. Website: http://matthieu-brucher.developpez.com/ Blogs: http://matt.eifelle.com and http://blog.developpez.com/?blog=92 LinkedIn: http://www.linkedin.com/in/matthieubrucher ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] scipy 0.7.1rc2 released
Matthieu Brucher wrote: Concerning the other errors: did you compile with intel compilers or GNU ones ? Only Intel compilers. Maybe I should check the rc branch instead of the trunk? I just wanted to confirm - I am actually rather surprised there are not more errors :) cheers, David ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] scipy 0.7.1rc2 released
On Fri, Jun 5, 2009 at 06:09, David Cournapeaucourn...@gmail.com wrote: Please test it ! I am particularly interested in results for scipy binaries on mac os x (do they work on ppc). Test suite passes on Intel Mac OS X (10.5.7) built from source: OK (KNOWNFAIL=6, SKIP=21) nose.result.TextTestResult run=3486 errors=0 failures=0 Cheers Adam ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] scipy 0.7.1rc2 released
Hi, The RC2 for 0.7.1 scipy release has just been tagged. This is a bug-fixes only release, see below for the release notes. More information can also be found on the trac website: http://projects.scipy.org/scipy/milestone/0.7.1 The only code change compared to the RC1 is one fix which is essential for mac os x/python 2.6 combination. Tarballs, windows and mac os x binaries are available. Please test it ! I am particularly interested in results for scipy binaries on mac os x (do they work on ppc). The scipy developers -- = SciPy 0.7.1 Release Notes = .. contents:: SciPy 0.7.1 is a bug-fix release with no new features compared to 0.7.0. scipy.io Bugs fixed: - Several fixes in Matlab file IO scipy.odr = Bugs fixed: - Work around a failure with Python 2.6 scipy.signal Memory leak in lfilter have been fixed, as well as support for array object Bugs fixed: - #880, #925: lfilter fixes - #871: bicgstab fails on Win32 scipy.sparse Bugs fixed: - #883: scipy.io.mmread with scipy.sparse.lil_matrix broken - lil_matrix and csc_matrix reject now unexpected sequences, cf. http://thread.gmane.org/gmane.comp.python.scientific.user/19996 scipy.special = Several bugs of varying severity were fixed in the special functions: - #503, #640: iv: problems at large arguments fixed by new implementation - #623: jv: fix errors at large arguments - #679: struve: fix wrong output for v 0 - #803: pbdv produces invalid output - #804: lqmn: fix crashes on some input - #823: betainc: fix documentation - #834: exp1 strange behavior near negative integer values - #852: jn_zeros: more accurate results for large s, also in jnp/yn/ynp_zeros - #853: jv, yv, iv: invalid results for non-integer v 0, complex x - #854: jv, yv, iv, kv: return nan more consistently when out-of-domain - #927: ellipj: fix segfault on Windows - #946: ellpj: fix segfault on Mac OS X/python 2.6 combination. - ive, jve, yve, kv, kve: with real-valued input, return nan for out-of-domain instead of returning only the real part of the result. Also, when ``scipy.special.errprint(1)`` has been enabled, warning messages are now issued as Python warnings instead of printing them to stderr. scipy.stats === - linregress, mannwhitneyu, describe: errors fixed - kstwobign, norm, expon, exponweib, exponpow, frechet, genexpon, rdist, truncexpon, planck: improvements to numerical accuracy in distributions Windows binaries for python 2.6 === python 2.6 binaries for windows are now included. The binary for python 2.5 requires numpy 1.2.0 or above, and and the one for python 2.6 requires numpy 1.3.0 or above. Universal build for scipy = Mac OS X binary installer is now a proper universal build, and does not depend on gfortran anymore (libgfortran is statically linked). The python 2.5 version of scipy requires numpy 1.2.0 or above, the python 2.6 version requires numpy 1.3.0 or above. Checksums = 08cdf8d344535fcb5407dafd9f120b9b release/installers/scipy-0.7.1rc2.tar.gz 93595ca9f0b5690a6592c9fc43e9253d release/installers/scipy-0.7.1rc2-py2.6-macosx10.5.dmg fc8f434a9b4d76f1b38b7025f425127b release/installers/scipy-0.7.1rc2.zip 8cdc2472f3282f08a703cdcca5c92952 release/installers/scipy-0.7.1rc2-win32-superpack-python2.5.exe 15c4c45de931bd7f13e4ce24bd59579e release/installers/scipy-0.7.1rc2-win32-superpack-python2.6.exe e42853e39b3b4f590824e3a262863ef6 release/installers/scipy-0.7.1rc2-py2.5-macosx10.5.dmg ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
