Mailman 3 June 2006 - SciPy-Dev

ANN: SciPy 2006 Conference Reminder
by Travis N. Vaught 30 Jun '06

30 Jun '06

The *SciPy 2006 Conference* is scheduled for Thursday and Friday, August 17-18, 2006 at CalTech with Sprints and Tutorials Monday-Wednesday, August 14-16. Conference details are at http://www.scipy.org/SciPy2006 The deadlines for submitting abstracts and early registration are approaching... Call for Presenters ------------------- If you are interested in presenting at the conference, you may submit an abstract in Plain Text, PDF or MS Word formats to abstracts at scipy.org <http://mail.python.org/mailman/listinfo/python-announce-list> -- the deadline for abstract submission is July 7, 2006. Papers and/or presentation slides are acceptable and are due by August 4, 2006. Registration: ------------- Early registration ($100.00) is still available through July 14. You may register online at http://www.enthought.com/scipy06. Registration includes breakfast and lunch Thursday & Friday and a very nice dinner Thursday night. After July 14, 2006, registration will cost $150.00. Tutorials and Sprints --------------------- This year the Sprints (Monday and Tuesday, August 14-15) and Tutorials (Wednesday, August 16) are no additional charge (you're on your own for food on those days, though). Remember to include these days in your travel plans. The following topics are presented as Tutorials Wednesday (more info here: http://www.scipy.org/SciPy2006/TutorialSessions): - "3D visualization in Python using tvtk and MayaVi" - "Scientific Data Analysis and Visualization using IPython and Matplotlib." - "Building Scientific Applications using the Enthought Tool Suite (Envisage, Traits, Chaco, etc.)" - "NumPy (migration from Numarray & Numeric, overview of NumPy)" The Sprint topics are under discussion here: http://www.scipy.org/SciPy2006/CodingSprints See you in August! Travis

1 0

QR factorization: modifications
by Bart Vandereycken 30 Jun '06

30 Jun '06

Hi all, I've modified the QR routine in scipy.linalg.qr in 3 ways, to make it faster and more compatible with Matlab. This is my first patch so any feedback is appreciated... you can find the files here: http://www.cs.kuleuven.be/~bartvde/scipy/ 1) The original method used only one LAPACK-routine (GEQRF) to compute the R factor, but NOT the (xORGQR and xUNGQR) to compute the Q factor. This is a huge efficiency loss, see the figure at my site for a comparison of the old and new qr method. I included the 2 LAPACK-wrappers in patch_flapack.diff and the new qr method in patch_qr.diff. (I don't use clapack, so I can't test this.) The old qr method is still available as qr_old in case you want to compare the results, use test_qr.py ;-) 2) You can compute economy-sized (as Matlab calls it) or skinny QR factorizations for tall matrices (more rows than cols). The performance gain should be obvious now. 3) If you only want the R factor and not the Q, the method stops early and is 2 times faster. Testing for test_decompy.py is included in patch_test.diff. There are 2 new parameters for scipy.decomp.qr: econ=False: economy size or not -> Matlab's qr(A,0) mode='qr': 'qr' or 'r' (or 'qre', qr with Givens rotations, maybe I'll do this later) -> Matlab's Q,R=qr(A) or R=qr(A) or Q,R,E=qr(A) Bart

2 1

band matrix wrapping ready for inclusion
by Arnd Baecker 30 Jun '06

30 Jun '06

Hi, thanks to Johannes Loehnert and Waltraut Wustmann the previous f2py wrappers have been supplied with many more unit-tests, documentation and wrappers for hermitian band matrices. The wrappers deals with: <s,d>sbev <s,d>sbevd <s,d>sbevx <c,z>hbevd <c,z>hbevx <s,d,c,z>gbtrf <s,d,c,z>gbtrs <s,d>lamch In addition front-end routines `eig_banded`, `eigvals_banded` for inclusion in Lib/linalg/decomp.py are provided. The current version is at http://www.physik.tu-dresden.de/~baecker/python/band.zip Pearu, it would be nice if you could have a look at the wrappers and let us know whether anything needs to be done/improved. If you prefer I can do a commit (after following the steps in the TODO), but I would like to get your ok first (I also don't mind if you prefer to make the corresponding changes ;-). Hope the result is useful not just for us but also to others. In addition, the contents of band.zip might be helpful as an example on how to provide wrappers for other LAPACK routines. Best, Arnd P.S.: In the long run one could also think of adding code for performing inverse iteration, but this might also fit into the sparse matrix department.

3 9

eig_banded
by Nils Wagner 30 Jun '06

30 Jun '06

Eigenvalues and Decompositions: eig --- Find the eigenvalues and vectors of a square matrix eigvals --- Find the eigenvalues of a square matrix lu --- LU decomposition of a matrix lu_factor --- LU decomposition returning unordered matrix and pivots lu_solve --- solve Ax=b using back substitution with output of lu_factor svd --- Singular value decomposition of a matrix svdvals --- Singular values of a matrix diagsvd --- construct matrix of singular values from output of svd orth --- construct orthonormal basis for range of A using svd cholesky --- Cholesky decomposition of a matrix cho_factor --- Cholesky decomposition for use in solving linear system cho_solve --- Solve previously factored linear system qr --- QR decomposition of a matrix schur --- Schur decomposition of a matrix rsf2csf --- Real to complex schur form hessenberg --- Hessenberg form of a matrix An entry for eig_banded is missing. Nils

2 1

scipy.stats.zs
by Tim Leslie 30 Jun '06

30 Jun '06

The function scipy.stats.zs, which calculates the z-score of each element of an array, currently recalculates the mean and samplestd for each element, which leads to an O(n^2) running time. Writing the function as follows fixes this and brings it back to O(n) running time. def zs (a): """ Returns a 1D array of z-scores, one for each score in the passed array, computed relative to the passed array. """ mu = mean(a, None) sigma = samplestd(a) return array([(score - mu)/sigma for score in a]) I'm having a few issues with both svn and trac right now, so I can't provide a patch or lodge a ticket, but I'll try to do something about that when I get on to a less broken machine later tonight if noone's picked this up by then. Cheers, Tim Leslie

2 1

author of test_cobyla.py
by Nils Wagner 30 Jun '06

30 Jun '06

Hi all, Who is the author of test_cobyla.py ? I would like to know the origin of the example. function = lambda x: x[0]**2 + abs(x[1])**3 con1 = lambda x: x[0]**2 + x[1]**2 - 25 con2 = lambda x: -con1(x) Nils

1 0

Anyone know how to get SciPy on MacBook Pro Intel
by Travis Oliphant 29 Jun '06

29 Jun '06

I just got a nice shiny MacBook Pro with the Intel chip. It looks like a nice and slick piece of hardware. Besides the ugly issues of fat-binaries, fink vs. darwinports, etc. it looks like g77 has not been ported to the Mac Intel. I've heard reports that gfortran does not work for SciPy. I was able to get the sources to compile but then had linking errors on import (is that the usual behavior other people see). Anyway, I've played with it too long. I'd hate to see my macbook pro go under-utilized because I can't get SciPy working on it. -Travis

4 5

Mail and mailing list migration
by Jeff Strunk 29 Jun '06

29 Jun '06

Good Afternoon, Tomorrow morning at about 10:00am Central time I will migrate the Mailman mailing lists from old.scipy.org to new.scipy.org. Any mail sent to mail.scipy.org after that time will end up at new.scipy.org. This will cause a short delay in mailing list delivery in the morning. Thank you, Jeff Strunk IT Administrator Enthought Inc.

1 1

cgemv test failure
by Arnd Baecker 28 Jun '06

28 Jun '06

Hi, on 64 Bit I get with 0.5.0.2000: ====================================================================== FAIL: check_x_stride_transpose (scipy.linalg.tests.test_fblas.test_cgemv) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/abaecker/BUILDS3/BuildDir/inst_numpy/lib/python2.4/site-packages/scipy/linalg/tests/test_fblas.py", line 348, in check_x_stride_transpose assert_array_almost_equal(desired_y,y) File "/home/abaecker/BUILDS3/BuildDir/inst_numpy/lib/python2.4/site-packages/numpy/testing/utils.py", line 222, in assert_array_almost_equal header='Arrays are not almost equal') File "/home/abaecker/BUILDS3/BuildDir/inst_numpy/lib/python2.4/site-packages/numpy/testing/utils.py", line 207, in assert_array_compare assert cond, msg AssertionError: Arrays are not almost equal (mismatch 33.3333333333%) x: array([ 12.88130569-12.88130569j, -13.69222832+15.69222832j, -12.8252039 +16.82520294j], dtyp y: array([ 12.88130569-12.88130569j, -13.69222832+15.69222832j, -12.8252039 +16.82520485j], dtyp The only warnings related to cgemv during the build were: gcc: Lib/linsolve/SuperLU/SRC/cpanel_bmod.c Lib/linsolve/SuperLU/SRC/cpanel_bmod.c:31: warning: function declaration isn't a prototype Lib/linsolve/SuperLU/SRC/cpanel_bmod.c: In function `cpanel_bmod': Lib/linsolve/SuperLU/SRC/cpanel_bmod.c:229: warning: implicit declaration of function `ctrsv_' Lib/linsolve/SuperLU/SRC/cpanel_bmod.c:276: warning: implicit declaration of function `cgemv_' gcc: Lib/linsolve/SuperLU/SRC/csnode_bmod.c The only pointer warnings during the build were: compile options: '-DATLAS_INFO="\"3.7.11\"" -I/scr/python/include -Ibuild/src.linux-x86_64-2.4 -I/home/abaecker/BUILDS3/BuildDir/inst_numpy/lib/python2.4/site-packages/numpy/core/include -I/scr/python/include/python2.4 -c' gcc: build/src.linux-x86_64-2.4/build/src.linux-x86_64-2.4/scipy/linalg/flapackmodule.c build/src.linux-x86_64-2.4/build/src.linux-x86_64-2.4/scipy/linalg/flapackmodule.c: In function `f2py_rout_flapack_cheev': build/src.linux-x86_64-2.4/build/src.linux-x86_64-2.4/scipy/linalg/flapackmodule.c:9761: warning: passing arg 6 of pointer to function from incompatible pointer type build/src.linux-x86_64-2.4/build/src.linux-x86_64-2.4/scipy/linalg/flapackmodule.c: In function `f2py_rout_flapack_zheev': build/src.linux-x86_64-2.4/build/src.linux-x86_64-2.4/scipy/linalg/flapackmodule.c:9945: warning: passing arg 6 of pointer to function from incompatible pointer type /scr/python/bin/g77 -shared build/temp.linux-x86_64-2.4/build/src.linux-x86_64-2.4/build/src.linux-x86_64-2.4/scipy/linalg/flapackmodule.o build/temp.linux-x86_64-2.4/build/src.linux-x86_64-2.4/fortranobject.o -L/scr/python/lib64 -Lbuild/temp.linux-x86_64-2.4 -llapack -lptf77blas -lptcblas -latlas -lg2c -o build/lib.linux-x86_64-2.4/scipy/linalg/flapack.so building 'scipy.linalg.clapack' extension compiling C sources C compiler: gcc -pthread -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -fPIC Best, Arnd

8 13

dot() and the fate of matrixmultiply()
by Neilen Marais 27 Jun '06

27 Jun '06

Hi With the recent API cleanup in numpy SVN, it seems matrixmultiply() has been removed. I know that dot() does the same thing, but I prefer to use matrixmultiply() since it makes my code easier to understand. Whenever I read dot() I think only of the inner product of two vectors. Also, I'd expect dot() to be a commutative operation, which matrix multiplication is not. Can I make an appeal for matrixmultiply()'s life? I can offer some anecdotal evidence in support for matrixmultiply()'s life: I was a tutor at the recent Py4Science workshop held at Stellenbosch (http://mentat.za.net/py4science/). It was fairly well attended by mathematicians and applied mathematicians, and while they were for the most part well impressed with Python/NumPy/SciPy I heard several of them mutter: "But it's not dot! Dot is for vectors!" when we were doing an example that involved matrix multiplication. I rather identify with them :) Regards Neilen

1 0