ANN: SciPy 0.7.0b1 (beta release)
I'm pleased to announce the first beta release of SciPy 0.7.0. 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 beta release comes almost one year after the 0.6.0 release and contains many new features, numerous bug-fixes, improved test coverage, and better documentation. Please note that SciPy 0.7.0b1 requires Python 2.4 or greater and NumPy 1.2.0 or greater. For information, please see the release notes: http://sourceforge.net/project/shownotes.php?group_id=27747&release_id=642769 You can download the release from here: http://sourceforge.net/project/showfiles.php?group_id=27747&package_id=19531&release_id=642769 Thank you to everybody who contributed to this release. Enjoy, -- Jarrod Millman Computational Infrastructure for Research Labs 10 Giannini Hall, UC Berkeley phone: 510.643.4014 http://cirl.berkeley.edu/
I have intel mkl on linux (x86_64) installed here: /opt/intel/mkl/10.0.5.025 How do I build scipy-0.7.0b1 using this?
Hi Neal, Add : [mkl] library_dirs = /opt/intel/mkl/10.0.5.025/lib/em64t lapack_libs = libmkl_lapack.a mkl_libs = libmkl_intel_lp64.a,libmkl_intel_thread.a,libmkl_core.a,iomp5,guide I think scipy has the same issue than numpy with the mkl, so it will not work unless you use the static MKL libraries (and not the shared ones, as it is the acse by default). Unfortunately, I didn't find out how to do this... Although I have the static libraries in my path, they are not found by python setup.py config. Matthieu 2008/11/26 Neal Becker <ndbecker2@gmail.com>:
I have intel mkl on linux (x86_64) installed here:
/opt/intel/mkl/10.0.5.025
How do I build scipy-0.7.0b1 using this?
_______________________________________________ Scipy-dev mailing list Scipy-dev@scipy.org http://projects.scipy.org/mailman/listinfo/scipy-dev
-- 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
TESTING ======= To test SciPy after installation (highly recommended), execute in Python
import scipy scipy.test(level=1)
Can scipy be tested _before_ installation? That would be helpful to add tests to the .spec file used for rpm build.
David Cournapeau wrote:
Neal Becker wrote:
Can scipy be tested _before_ installation? That would be helpful to add tests to the .spec file used for rpm build.
What do you mean by testing before installation ?
David
Build scipy, don't install, then test it in place. Nice to know if it passes the tests before I install and overwrite my known good version.
Neal Becker wrote:
Build scipy, don't install, then test it in place. Nice to know if it passes the tests before I install and overwrite my known good version.
You can simply install several versions in parallel, using something like stow if you are on unix. That's what I use to easily switch between a stable version for my research and last svn version when developing numpy/scipy. Even simpler, you can first install it in a temporary directory to test it. cheers, David
2008/11/26 David Cournapeau <david@ar.media.kyoto-u.ac.jp>:
You can simply install several versions in parallel, using something like stow if you are on unix. That's what I use to easily switch between a stable version for my research and last svn version when developing numpy/scipy. Even simpler, you can first install it in a temporary directory to test it.
I.e. (unverified, but you get the idea): STAGE=/path/to/stage SCIPY=/path/to/scipy mkdir ${STAGE} cd ${SCIPY} python setup.py install --prefix=${STAGE} cd export PYTHONPATH=${STAGE} python -c 'import scipy; scipy.test(level=1) Cheers Stéfan
Using windows installer on windowsXP, sse2, Pentium M: slow but no errors or failures
scipy.test(level=1) Running unit tests for scipy NumPy version 1.2.1 NumPy is installed in C:\Programs\Python25\lib\site-packages\numpy SciPy version 0.7.0.dev5180 SciPy is installed in C:\Programs\Python25\lib\site-packages\scipy Python version 2.5.2 (r252:60911, Feb 21 2008, 13:11:45) [MSC v.1310 32 bit (Intel)]
Ran 3688 tests in 508.000s OK (KNOWNFAIL=2, SKIP=31) <nose.result.TextTestResult run=3688 errors=0 failures=0> The only very minor caveat is a warning about not removing a temp directory, but it is pretty common that installers and tests leave some temporary files and directories lying around in the default temp directory. Just out of curiosity: which part of scipy is producing temporary matrix market files, each test run is producing around 20 of those file: tmpyqkvrg.mtx --------- %%MatrixMarket matrix array complex hermitian % 2 2 1.0000000000000000e+000 0.0000000000000000e+000 2.0000000000000000e+000 -3.0000000000000000e+000 4.0000000000000000e+000 0.0000000000000000e+000 ---------- Josef
On Wed, Nov 26, 2008 at 11:25 AM, <josef.pktd@gmail.com> wrote:
Using windows installer on windowsXP, sse2, Pentium M
scipy.test(level=1) : level is depreciated and I get the same results with level=10 as with level=1 I build scipy beta source package from sourceforge with mingw: * scipy.test(level=1) gives the same successful result as the installer * scipy.test('full') end with a segfault, that I always got with one weave example nosetests pathto\scipy\weave\tests\test_ext_tools.py:TestExtModule.test_with_include ends with a segfault I think the offending code is the writing to stdout from c: code = """ std::cout << std::endl; std::cout << "test printing a value:" << a << std::endl; """ As Robert Kern mentioned several times, MinGW has a problem with stdout. Is it possible to skip this test when the compiler for weave is mingw, or change the code in the test if the purpose of the test is to test an include instead of testing stdout? After skipping this test, except for knownfailures and skips all tests pass. however, 2 knownfailures are counted as errors (maybe another problem with nose decorators):
nosetests pathto\scipy\weave\tests\ <snip>
====================================================================== ERROR: test_char_fail (test_scxx_dict.TestDictGetItemOp) ---------------------------------------------------------------------- Traceback (most recent call last): File "C:\Programs\Python25\lib\site-packages\numpy\testing\decorators.py", lin e 119, in skipper raise KnownFailureTest, msg KnownFailureTest: Test skipped due to known failure ====================================================================== ERROR: test_obj_fail (test_scxx_dict.TestDictGetItemOp) ---------------------------------------------------------------------- Traceback (most recent call last): File "C:\Programs\Python25\lib\site-packages\numpy\testing\decorators.py", lin e 119, in skipper raise KnownFailureTest, msg KnownFailureTest: Test skipped due to known failure ---------------------------------------------------------------------- Ran 449 tests in 775.250s FAILED (SKIP=8, errors=2) Josef
Fedora F9 x86_64: FAIL: test_pbdv (test_basic.TestCephes) ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/lib64/python2.5/site-packages/scipy/special/tests/test_basic.py", line 357, in test_pbdv assert_equal(cephes.pbdv(1,0),(0.0,0.0)) File "/usr/lib64/python2.5/site-packages/numpy/testing/utils.py", line 176, in assert_equal assert_equal(actual[k], desired[k], 'item=%r\n%s' % (k,err_msg), verbose) File "/usr/lib64/python2.5/site-packages/numpy/testing/utils.py", line 183, in assert_equal raise AssertionError(msg) AssertionError: Items are not equal: item=1 ACTUAL: 1.0 DESIRED: 0.0
Fedora F9 x86_64:
FAIL: test_pbdv (test_basic.TestCephes) ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/lib64/python2.5/site-packages/scipy/special/tests/test_basic.py", line 357, in test_pbdv assert_equal(cephes.pbdv(1,0),(0.0,0.0)) File "/usr/lib64/python2.5/site-packages/numpy/testing/utils.py", line 176, in assert_equal assert_equal(actual[k], desired[k], 'item=%r\n%s' % (k,err_msg), verbose) File "/usr/lib64/python2.5/site-packages/numpy/testing/utils.py", line 183, in assert_equal raise AssertionError(msg) AssertionError: Items are not equal: item=1
ACTUAL: 1.0 DESIRED: 0.0
Ok I can reproduce this one on intrepid ibex 64bits (gfortran). The funny think is that I think (if I read the correct mathword pages) that 1.0 is the correct answer (but it is so easy to be wrong with these special function). Xavier
On Mon, Dec 1, 2008 at 8:12 AM, Xavier Gnata <xavier.gnata@gmail.com> wrote:
Ok I can reproduce this one on intrepid ibex 64bits (gfortran). The funny think is that I think (if I read the correct mathword pages) that 1.0 is the correct answer (but it is so easy to be wrong with these special function).
I can't reproduce on RHEL 5 (64 bits/python2.4). I opened a ticket: http://scipy.org/scipy/scipy/ticket/803 Neal, Xavier, which version of numpy are you using ? Which version of gcc is used in FC 9 ? thanks, David
David Cournapeau wrote:
On Mon, Dec 1, 2008 at 8:12 AM, Xavier Gnata <xavier.gnata@gmail.com> wrote:
Ok I can reproduce this one on intrepid ibex 64bits (gfortran). The funny think is that I think (if I read the correct mathword pages) that 1.0 is the correct answer (but it is so easy to be wrong with these special function).
I can't reproduce on RHEL 5 (64 bits/python2.4). I opened a ticket:
http://scipy.org/scipy/scipy/ticket/803
Neal, Xavier, which version of numpy are you using ? Which version of gcc is used in FC 9 ?
thanks,
David : numpy.__version__ Out[3]: '1.2.0'
gcc-4.3.0-8.x86_64
On Mon, Dec 1, 2008 at 8:12 AM, Xavier Gnata <xavier.gnata@gmail.com> wrote:
Ok I can reproduce this one on intrepid ibex 64bits (gfortran). The funny think is that I think (if I read the correct mathword pages) that 1.0 is the correct answer (but it is so easy to be wrong with these special function). I can't reproduce on RHEL 5 (64 bits/python2.4). I opened a ticket:
http://scipy.org/scipy/scipy/ticket/803
Neal, Xavier, which version of numpy are you using ? Which version of gcc is used in FC 9 ?
thanks,
David : numpy.__version__ Out[3]: '1.2.0'
gcc-4.3.0-8.x86_64
It is starting to be a bit fun :) gcc version 4.3.2 (Ubuntu 4.3.2-1ubuntu11) no g77, only gfortran numpy.__version__ '1.3.0.dev6129' scipy.__version__ '0.7.0.dev5213' If there is any other test I should do please tell (I have no time to try to really debug this week but I can perform tests). Xavier
Xavier Gnata wrote:
On Mon, Dec 1, 2008 at 8:12 AM, Xavier Gnata <xavier.gnata@gmail.com> wrote:
Ok I can reproduce this one on intrepid ibex 64bits (gfortran). The funny think is that I think (if I read the correct mathword pages) that 1.0 is the correct answer (but it is so easy to be wrong with these special function).
I can't reproduce on RHEL 5 (64 bits/python2.4). I opened a ticket:
http://scipy.org/scipy/scipy/ticket/803
Neal, Xavier, which version of numpy are you using ? Which version of gcc is used in FC 9 ?
thanks,
David
: numpy.__version__ Out[3]: '1.2.0'
gcc-4.3.0-8.x86_64
It is starting to be a bit fun :)
gcc version 4.3.2 (Ubuntu 4.3.2-1ubuntu11) no g77, only gfortran numpy.__version__ '1.3.0.dev6129' scipy.__version__ '0.7.0.dev5213'
If there is any other test I should do please tell (I have no time to try to really debug this week but I can perform tests).
Xavier _______________________________________________ Scipy-dev mailing list Scipy-dev@scipy.org http://projects.scipy.org/mailman/listinfo/scipy-dev
Hi I also get this on my system: Linux x86-64 Fedora rawhide/10 using Fedora Python 2.5.2 (r252:60911), GCC (4.3.2 20080917 (Red Hat 4.3.2-4)), and Fedora supplied blas/atlas libraries. My Numpy is '1.3.0.dev6006' or an earlier version of 1.3 but Numpy was not built with any blas/atlas libraries. (Yes, scipy will build if a site.cfg is provided otherwise it will not because it looks at the numpy installation). It also fails for Python 2.4.5 built from source using gcc 4.3.2 Python 2.6 (r26:66714, Oct 2 2008, 11:15:01) built from source using gcc 4.3.2 - others also fail here. Bruce
On Wed, Nov 26, 2008 at 00:04, Jarrod Millman <millman@berkeley.edu> wrote:
I'm pleased to announce the first beta release of SciPy 0.7.0.
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 beta release comes almost one year after the 0.6.0 release and contains many new features, numerous bug-fixes, improved test coverage, and better documentation. Please note that SciPy 0.7.0b1 requires Python 2.4 or greater and NumPy 1.2.0 or greater.
For information, please see the release notes: http://sourceforge.net/project/shownotes.php?group_id=27747&release_id=642769
You can download the release from here: http://sourceforge.net/project/showfiles.php?group_id=27747&package_id=19531&release_id=642769
Thank you to everybody who contributed to this release.
Just tried build on Mac OS X Leopard using MacPorts python and I'm getting the following build error: building 'arpack' library compiling C sources C compiler: /usr/bin/gcc-4.0 -fno-strict-aliasing -Wno-long-double -no-cpp-precomp -mno-fused-madd -fno-common -dynamic -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes error: file 'ARPACK/FWRAPPERS/veclib_cabi_c.c' does not exist Anyone seen this? Cheers Adam
On Thu, Nov 27, 2008 at 1:23 AM, Adam Mercer <ramercer@gmail.com> wrote:
Just tried build on Mac OS X Leopard using MacPorts python and I'm getting the following build error:
That's a bug in the arpack build file. It should be fixed in SVN, David
On Wed, Nov 26, 2008 at 18:20, David Cournapeau <cournape@gmail.com> wrote:
On Thu, Nov 27, 2008 at 1:23 AM, Adam Mercer <ramercer@gmail.com> wrote:
Just tried build on Mac OS X Leopard using MacPorts python and I'm getting the following build error:
That's a bug in the arpack build file. It should be fixed in SVN,
I'm assuming thats r5199? Applying that change to the 0.7.0b1 tarball results in the same error. Cheers Adam
On Wed, Nov 26, 2008 at 19:51, Adam Mercer <ramercer@gmail.com> wrote:
That's a bug in the arpack build file. It should be fixed in SVN,
I'm assuming thats r5199? Applying that change to the 0.7.0b1 tarball results in the same error.
Ok, building from the trunk works so I must have mucked something up. Ignore the noise. Cheers Adam
On Thu, Nov 27, 2008 at 10:57 AM, Adam Mercer <ramercer@gmail.com> wrote:
On Wed, Nov 26, 2008 at 19:51, Adam Mercer <ramercer@gmail.com> wrote:
That's a bug in the arpack build file. It should be fixed in SVN,
I'm assuming thats r5199? Applying that change to the 0.7.0b1 tarball results in the same error.
Ok, building from the trunk works so I must have mucked something up. Ignore the noise.
No, you may be right :) The problem is specific to the tarball (the file exists in subversion, it is not included in the tarball). To test whether the fix is OK, you should first generate the tarball from the trunk: python setup.py sdist And then use the generated tarball as the source tree to build. David
On Wed, Nov 26, 2008 at 22:24, David Cournapeau <cournape@gmail.com> wrote:
No, you may be right :) The problem is specific to the tarball (the file exists in subversion, it is not included in the tarball). To test whether the fix is OK, you should first generate the tarball from the trunk:
python setup.py sdist
And then use the generated tarball as the source tree to build.
Just build from a tarball created from r5203, and it builds without issue on Mac OS X Leopard, Python-2.5.2: OK (KNOWNFAIL=2, SKIP=21) <nose.result.TextTestResult run=3374 errors=0 failures=0> Cheers Adam
Python 2.5 superpack on Win XP SP 3: Ran 3688 tests in 412.203s OK (KNOWNFAIL=2, SKIP=28) <nose.result.TextTestResult run=3688 errors=0 failures=0> Alan Isaac
participants (11)
-
Adam Mercer -
Alan G Isaac -
Bruce Southey -
David Cournapeau -
David Cournapeau -
Jarrod Millman -
josef.pktd＠gmail.com -
Matthieu Brucher -
Neal Becker -
Stéfan van der Walt -
Xavier Gnata