Mailman 3 October 2004 - SciPy-Dev

ANN: SciPy 0.3.2 Released
by Pearu Peterson Oct. 13, 2004

Oct. 13, 2004

Hi, Scipy 0.3.2 has been released and binaries are available from the scipy.org site: http://www.scipy.org Scipy 0.3.2 is a bug fix release of Scipy 0.3 including the following new features: - wxPython 2.5 support - reading/writing dense/sparse matrices in Matrix Market format - iterative solvers, new functions sqrtm, hessenberg - Constrained Optimization BY Linear Approximation - discrete Boltzmann, Planck, Levy distributions - Scipy tests pass now also on 64-bit systems and Mac OSX etc. The complete release notes can be found here: http://www.scipy.org/download/scipy_release_notes_0.3.2.html Best regards, Pearu BTW Scipy is: ------------- Scipy is an open source library of scientific tools for Python. Scipy supplements the popular Numeric module, gathering a variety of high level science and engineering modules together as a single package. Scipy includes modules for graphics and plotting, optimization, integration, special functions, signal and image processing, genetic algorithms, ODE solvers, and others.

1 0

Weave: ext_module headers problems
by Prabhu Ramachandran Oct. 13, 2004

Oct. 13, 2004

Hi, This question is mostly for Eric. In ext_tools.ext_module this is the definition of build_information: def build_information(self): info = [self.customize] + self._build_information + \ self.arg_specs().build_information() # ... This means that any headers added via ext_module.customize.add_header('foo') are added *before* Python.h and this triggers warnings when the functions are compiled. This is also what is invoked for all weave.inline calls (see inline_tools.py line 433). To get around this I've changed the definition to: def build_information(self): info = self._build_information + [self.customize] +\ self.arg_specs().build_information() # ... This fixes the warnings and puts the user headers last. I am not sure there is any specific reason that you put self.customize first. I just thought I'd check with you before checking the change into CVS. Thanks. cheers, prabhu

2 3

CVS build just failed
by Fernando.Perez＠colorado.edu Oct. 12, 2004

Oct. 12, 2004

Hi all, I'm trying to build CVS scipy on a new Fedora Core 2 box, and I'm failing pretty early on. I suspect the problem is with f2py and not scipy itself. Here's the error: ... compiling Fortran sources g77(f77) options: '-Wall -fno-second-underscore -Vaxlib -i_dynamic -O3 -funroll- loops -march=pentium4 -mmmx -msse2 -msse -malign-double -fomit-frame-pointer' ifc(f90) options: '-Vaxlib -i_dynamic -Vaxlib -i_dynamic -O3 -funroll-loops -mar ch=pentium4 -mmmx -msse2 -msse -malign-double -fomit-frame-pointer' ifc(fix) options: '-Vaxlib -i_dynamic -Vaxlib -i_dynamic -O3 -funroll-loops -mar ch=pentium4 -mmmx -msse2 -msse -malign-double -fomit-frame-pointer' compile options: '-c' g77:f77: Lib/fftpack/dfftpack/dcosqb.f g77: `-V' must come at the start of the command line g77: `-V' must come at the start of the command line error: Command "/usr/bin/g77 -Wall -fno-second-underscore -Vaxlib -i_dynamic -O3 -funroll-loops -march=pentium4 -mmmx -msse2 -msse -malign-double -fomit-frame-p ointer -c -c Lib/fftpack/dfftpack/dcosqb.f -o build/temp.linux-i686-2.3/Lib/fftp ack/dfftpack/dcosqb.o" failed with exit status 1 ### I grabbed the latest f2py from the webpage a moment ago (2.43.239_1844) and the scipy is current CVS. Any help would be much appreciated. best, f

3 5

RE: [SciPy-dev] scipy and ATLAS (in)dependency
by Perry Greenfield Oct. 11, 2004

Oct. 11, 2004

Pearu Peterson wrote: > Hi, > > Today I was reading "Special Session: Making Python attractive to > General Scientists (Harrington, Greenfield)" notes in > > http://www.scipy.org/wikis/scipy04/ConferenceSchedule > > and I was a bit surprised on one of the conclusions that maybe ATLAS > optimization should be undone due to difficulties in building ATLAS. > > Though, IMHO, building recent versions of ATLAS libraries is not > difficult > at all on Linux platforms and not even on MS Windows (there are > step-by-step instructions available on Scipy site), it just may be a very > time consuming process ;). > It's not even an issue for Mac as Scipy uses its vecLib framework. > I can't say much on the situation on other unix platforms such as irix, > sun, etc due to the lack of access to such platforms. But most of current > and potential Scipy users are either on MS Windows, Linux, or Mac anyway.. > > But that was not the point I was surprised on. It was acctually the fact > that people seem to be unaware of the possibility to build Scipy without > ATLAS dependency by using Fortran sources of BLAS and LAPACK libraries. > Let me stress that nothing in Scipy requires specifically ATLAS > libraries, > the corresponding interface in scipy.linalg is smart enough to pick up > ATLAS optimized routines when available and use Fortran BLAS/LAPACK > routines when they are not. > > My point is that there is (almost) nothing to do to "undo ATLAS > optimization" in Scipy. ATLAS is optional already. However, when ATLAS is > not available then Scipy needs BLAS/LAPACK libraries that currently must > be provided by the system or users must download them from > Netlib. I think > that BLAS/LAPACK libraries are the only external libraries that Scipy > currently depends on. > > To get rid of this dependency, I'd suggest include the sources of > BLAS/LAPACK libraries to Scipy, and use them silently when optimized > BLAS/LAPACK libraries are not available. This would be very similar to > scipy.fftpack that silently uses Fortran fftpack sources when FFTW > libraries are not found. > > Just wanted to clear some things up.. > Pearu > As one of the notetakers I'll admit I don't have much personal experience with the issue so I could have gotten the conversation wrong. But I think the gist was that some felt that there should be easy-to-install binary packaging for all popular platforms, not easy-to-build packaging (though of course one hopes that is also available). If having an optimized ATLAS got in the way of that goal, then it was argued that it would be better to have a slow version of the linear algebra libraries in the easy-to-install binaries. Those that needed the optimized versions could build it themselves. The stress was on making it very painless for people to install the general setup on their machines and that meant binary installers. If the conclusion that optimized atlas made that harder (either on the people doing the binary packaging--thus it never happens-- or the people doing the installing) is wrong, then I should correct the notes. But I think that was the point of the comments. Perry

5 4

scipy and ATLAS (in)dependency
by Pearu Peterson Oct. 9, 2004

Oct. 9, 2004

Hi, Today I was reading "Special Session: Making Python attractive to General Scientists (Harrington, Greenfield)" notes in http://www.scipy.org/wikis/scipy04/ConferenceSchedule and I was a bit surprised on one of the conclusions that maybe ATLAS optimization should be undone due to difficulties in building ATLAS. Though, IMHO, building recent versions of ATLAS libraries is not difficult at all on Linux platforms and not even on MS Windows (there are step-by-step instructions available on Scipy site), it just may be a very time consuming process ;). It's not even an issue for Mac as Scipy uses its vecLib framework. I can't say much on the situation on other unix platforms such as irix, sun, etc due to the lack of access to such platforms. But most of current and potential Scipy users are either on MS Windows, Linux, or Mac anyway.. But that was not the point I was surprised on. It was acctually the fact that people seem to be unaware of the possibility to build Scipy without ATLAS dependency by using Fortran sources of BLAS and LAPACK libraries. Let me stress that nothing in Scipy requires specifically ATLAS libraries, the corresponding interface in scipy.linalg is smart enough to pick up ATLAS optimized routines when available and use Fortran BLAS/LAPACK routines when they are not. My point is that there is (almost) nothing to do to "undo ATLAS optimization" in Scipy. ATLAS is optional already. However, when ATLAS is not available then Scipy needs BLAS/LAPACK libraries that currently must be provided by the system or users must download them from Netlib. I think that BLAS/LAPACK libraries are the only external libraries that Scipy currently depends on. To get rid of this dependency, I'd suggest include the sources of BLAS/LAPACK libraries to Scipy, and use them silently when optimized BLAS/LAPACK libraries are not available. This would be very similar to scipy.fftpack that silently uses Fortran fftpack sources when FFTW libraries are not found. Just wanted to clear some things up.. Pearu

3 2

python / mathematica
by Jelle Feringa // EZCT / Amsterdam Oct. 7, 2004

Oct. 7, 2004

Dear Mr Perez, I'm sorry to get back to a discussing which has been long due. My interest in combining the powers of both Mathematica and Python. I've been checking out for instance PY_ML, I'm sure you are aware of it, also the fact that its outdated (for Mathematica v3, I'm using 5) Could you be so kind to point me in the right direction for the interface as being discussed in the scipy forum? Best regards, Jelle Feringa. ------------------ http://www.scipy.org/documentation/mailman?fn=scipy-dev/2002-September/00116 2.html ----- On Fri, 13 Sep 2002, Mark Evans wrote: > My particular project involved an ActiveX chart control interfaced to > wxPython, and a Python interface to both Mathematica and Numerical Python. > We were creating a technical workspace environment with Python as the > front end and Numpy / Mathematica as cooperating back ends. > I can't tell you what relief I felt after I switched from CXX to Boost. That sounds very interesting. Did this project ever make it to the public? Here in my group we use Mathematica a _lot_ and I'm pushing python hard for the numerical parts (as a replacement for matlab, trying to only write C/Fortran when absolutely necessary). But being able to have the python and mathematica parts talk would be great. Could you provide a bit more info on this? Since it's a bit off the original thread topic, feel free to either respond privately or start a new thread. Cheers, f.

2 1

Bug in scipy import
by answer＠tnoo.net Oct. 7, 2004

Oct. 7, 2004

Hi There is a subtle bug in the import structure of scipy which nearly drove me crazy. Here is how to reproduce it: ==== import scipy ==== imports and executes any file named "new.py" in the current working directory. Python 2.3.3 (#1, Apr 6 2004, 01:47:39) [GCC 3.3.3 (SuSE Linux)] on linux2 scipy.__version__ '0.3.1_285.4270' Thanks, Martin -- Martin L�thi answer(a)tnoo.net

3 3

Re: [SciPy-dev] Re: Plan for releasing Scipy 0.3.2
by Travis Oliphant Oct. 7, 2004

Oct. 7, 2004

Berthold Höllmann wrote: >Pearu Peterson <pearu(a)scipy.org> writes: > > > >>Hi, >> >>I think we are ready to make the release: with the recent Scipy from >>CVS all tests pass ok on Debian (sid) P4 and AMD MP boxes, Gentoo >>Opteron box, and a WinNT box. >> >>If you think that there are some important bugs to be fixed, you still got >>about 12 hours. I plan to tag Scipy CVS tree tomorrow morning >>(Estonian time), create tar-balls, etc. See >> >> http://www.scipy.org/development/releasescipy.txt >> >>for relevant tasks. >> >>Please, let me know if there is any reason that I should hold on for >>tagging CVS tree. >> >>I can also make binaries for Linux system but it would be create if >>someone could create RPMs (Joe?) and Win32 installers (Travis?) after >>tar-balls are available. >> >> > >Testing the actual CVS on a SuSE 9.0 with gcc 3.4.2 I get > > > >>python -c "import scipy ; scipy.test()"/usr/local/lib/python2.4/whrandom.py:38: DeprecationWarning: the whrandom module is deprecated; please use the random module >> >> > DeprecationWarning) > !! No test file 'test_Mplot.py' found for <module 'scipy.xplt.Mplot' from '...-packages/scipy/xplt/Mplot.pyc'> >(lots of "!! No test..." and test output) >.Testing weibull_min >......... >====================================================================== >FAIL: check_basic (scipy.stats.morestats.test_morestats.test_shapiro) >---------------------------------------------------------------------- >Traceback (most recent call last): > File "/usr/local/lib/python2.4/site-packages/scipy/stats/tests/test_morestats.py", >line 40, in check_basic > assert_almost_equal(pw,0.52459925413131714,3) > File "/usr/local/lib/python2.4/site-packages/scipy_test/testing.py", line 606, in a >ssert_almost_equal > assert round(abs(desired - actual),decimal) == 0, msg >AssertionError: >Items are not equal: >DESIRED: 0.52459925413131714 >ACTUAL: 1.0 > >---------------------------------------------------------------------- >Ran 972 tests in 9.784s > > Do you get this error consistently or just once in a while? -Travis

3 4

Releasing Scipy 0.3.2, closing up
by Pearu Peterson Oct. 7, 2004

Oct. 7, 2004

Hi, I have created a branch for Scipy 0.3.2 release. To check it out, use cvs checkout -r v0_3_2 -d scipy_v0_3_2 scipy cd scipy_v0_3_2 cvs checkout -r v0_3_2 scipy_core (assuming that you have CVSROOT set properly). Use this branch *only* to create 0.3.2 Scipy source or binary distributions and for minor bug fixes. I have already uploaded 0.3.2 Scipy sources to http://www.scipy.org/download/scipy/src/ Now I'll start making statically linked binaries for Linux. Finally, we'll need: - RPMs (Travis,Joe?) - Win32 installers (Travis,Pearu?) - Update http://www.scipy.org/download/ page. - Sending out release announcements (Eric?, Travis?,..) Regards, Pearu

1 0

Plan for releasing Scipy 0.3.2
by Pearu Peterson Oct. 6, 2004

Oct. 6, 2004

Hi, I think we are ready to make the release: with the recent Scipy from CVS all tests pass ok on Debian (sid) P4 and AMD MP boxes, Gentoo Opteron box, and a WinNT box. If you think that there are some important bugs to be fixed, you still got about 12 hours. I plan to tag Scipy CVS tree tomorrow morning (Estonian time), create tar-balls, etc. See http://www.scipy.org/development/releasescipy.txt for relevant tasks. Please, let me know if there is any reason that I should hold on for tagging CVS tree. I can also make binaries for Linux system but it would be create if someone could create RPMs (Joe?) and Win32 installers (Travis?) after tar-balls are available. Thanks, Pearu

6 14