Mailman 3 April 2007 - SciPy-Dev

Compiling pysparse from the sandbox
by Neilen Marais April 20, 2007

April 20, 2007

Hi, I tried compiling pysparse from the sandbox in a recent svn SciPy, but I get the following compiler error: In file included from Lib/sandbox/pysparse/src/spmatrixmodule.c:17: Lib/sandbox/pysparse/src/ll_mat.c: In function ‘LLMat_matvec_transp’: Lib/sandbox/pysparse/src/ll_mat.c:760: error: ‘CONTIGUOUS’ undeclared (first use in this function) Lib/sandbox/pysparse/src/ll_mat.c:760: error: (Each undeclared identifier is reported only once Lib/sandbox/pysparse/src/ll_mat.c:760: error: for each function it appears in.) Lib/sandbox/pysparse/src/ll_mat.c: In function ‘LLMat_matvec’: Lib/sandbox/pysparse/src/ll_mat.c:797: error: ‘CONTIGUOUS’ undeclared (first use in this function) In file included from Lib/sandbox/pysparse/src/spmatrixmodule.c:18: Lib/sandbox/pysparse/src/csr_mat.c: In function ‘CSRMat_matvec_transp’: Lib/sandbox/pysparse/src/csr_mat.c:119: error: ‘CONTIGUOUS’ undeclared (first use in this function) Lib/sandbox/pysparse/src/csr_mat.c: In function ‘CSRMat_matvec’: Lib/sandbox/pysparse/src/csr_mat.c:146: error: ‘CONTIGUOUS’ undeclared (first use in this function) In file included from Lib/sandbox/pysparse/src/spmatrixmodule.c:19: Lib/sandbox/pysparse/src/sss_mat.c: In function ‘SSSMat_matvec’: Lib/sandbox/pysparse/src/sss_mat.c:83: error: ‘CONTIGUOUS’ undeclared (first use in this function) In file included from Lib/sandbox/pysparse/src/spmatrixmodule.c:17: Lib/sandbox/pysparse/src/ll_mat.c: In function ‘LLMat_matvec_transp’: Lib/sandbox/pysparse/src/ll_mat.c:760: error: ‘CONTIGUOUS’ undeclared (first use in this function) Lib/sandbox/pysparse/src/ll_mat.c:760: error: (Each undeclared identifier is reported only once Lib/sandbox/pysparse/src/ll_mat.c:760: error: for each function it appears in.) Lib/sandbox/pysparse/src/ll_mat.c: In function ‘LLMat_matvec’: Lib/sandbox/pysparse/src/ll_mat.c:797: error: ‘CONTIGUOUS’ undeclared (first use in this function) In file included from Lib/sandbox/pysparse/src/spmatrixmodule.c:18: Lib/sandbox/pysparse/src/csr_mat.c: In function ‘CSRMat_matvec_transp’: Lib/sandbox/pysparse/src/csr_mat.c:119: error: ‘CONTIGUOUS’ undeclared (first use in this function) Lib/sandbox/pysparse/src/csr_mat.c: In function ‘CSRMat_matvec’: Lib/sandbox/pysparse/src/csr_mat.c:146: error: ‘CONTIGUOUS’ undeclared (first use in this function) In file included from Lib/sandbox/pysparse/src/spmatrixmodule.c:19: Lib/sandbox/pysparse/src/sss_mat.c: In function ‘SSSMat_matvec’: Lib/sandbox/pysparse/src/sss_mat.c:83: error: ‘CONTIGUOUS’ undeclared (first use in this function) error: Command "gcc -pthread -fno-strict-aliasing -DNDEBUG -g -O2 -Wall -fPIC -ILib/sandbox/pysparse/include/ -I/usr/lib/python2.4/site-packages/numpy/core/include -I/usr/include/python2.4 -c Lib/sandbox/pysparse/src/spmatrixmodule.c -o build/temp.linux-x86_64-2.4/Lib/sandbox/pysparse/src/spmatrixmodule.o" failed with exit status 1 Is this a known problem, or have I forgotten to install some development library? I'm running Ubuntu Edgy AMD64. Thanks Neilen -- you know its kind of tragic we live in the new world but we've lost the magic -- Battery 9 (www.battery9.co.za)

9 11

Specifying library names when configuring numpy or scipy?
by Peter C. Norton April 19, 2007

April 19, 2007

Summary: With python-2.5.1c1, numpy-1.02, and scipy-0.52, the distutils included in numpy doesn't allow me to specify the name of my platform-specific optimized blas+lapack library in the blas_opt or blas_lapack sections. I've tried using the following names in the blas_opt and lapack_opt "libraries" sections: libsunperf, sunperf. To build and install scipy, I can create symlinks from the real location of libsunperf to a temporary location and then perform the build, as long as the names being symlinked to are "libblas.so" and "liblapack.so". This is a problem, since it means that to use scipy, I will need to have these symlinks in place somewhere in the loader's path, forever. I'm guessing this relates to my having the same problem with the numpy distutils package, but with numpy I could use a static library, and that keeps me from having to jerry-rig symlinks around my filesystem. scipy doesn't seem to work with static libraries. Is this inability to use alternative optimized library names on anyone's rader? I'm not familiar with distutils in general, or how it should work for numpy/scipy here, but I'd be happy to look at this and feedback on it. I'm guessing that the problem is that the classes blas_opt and lapack_opt need some fleshing out. Does this just need to be done still? Thanks, -Peter -- The 5 year plan: In five years we'll make up another plan. Or just re-use this one.

1 0

from scipy.sandbox import pysparse
by Nils Wagner April 18, 2007

April 18, 2007

Hi all, Compiling pysparse from the sandbox works for me but I cannot import pysparse. Traceback (most recent call last): File "/usr/lib64/python2.4/site-packages/scipy/sandbox/pysparse/tests/test_sparray.py", line 3, in ? from sparray import sparray ImportError: No module named sparray >>> from scipy.sandbox import pysparse Traceback (most recent call last): File "<stdin>", line 1, in ? File "/usr/lib64/python2.4/site-packages/scipy/sandbox/pysparse/__init__.py", line 4, in ? from spmatrix import * ImportError: No module named spmatrix >>> import scipy >>> scipy.__version__ '0.5.3.dev2933' Nils

1 0

petsc - UMFPACK and scipy
by Nils Wagner April 18, 2007

April 18, 2007

Ondrej, Please can you show me an example where petsc solvers are "better" than UMFPACK. Nils 4) About the petsc - I know it's another dependence. However, I noticed you are using umfpack in SciPy. So why not petsc? I think it contains much more (sometimes better) solvers (depends on the problem). It's seems logical to me, to either use nothing, or the best library available, which I believe is petsc.

7 19

Proposal for more generic optimizers (posted before on scipy-user)
by Matthieu Brucher April 17, 2007

April 17, 2007

Hi, I'm migratting toward Python for some weeks, but I do not find the tools I had to develop for my PhD in SciPy at the moment. I can't, for instance, find an elegant way to save the set of parameters used in an optimization for the standard algorithms. What is more, I think they can be more generic. What I did in C++, and I'd like your opinion about porting it in Python, was to define a standard optimizer with no iteration loop - iterate was a pure virtual method called by a optimize method -. This iteration loop was then defined for standard optimizer or damped optimizer. Each time, the parameters tested could be saved. Then, the step that had to be taken was an instance of a class that used a gradient step, a Newton step, ... and the same was used for the stoping criterion. The function was a class that defined value, gradient, hessian, ... if needed. For instance, a simplified instruction could have been : Optimizer* optimizer = StandardOptimizer</*some more parameters not relevant in Python*/(function, GradientStep(), SimpleCriterion(NbMaxIterations), step, saveParameters); optimizer->optimize(); optimizer->getOptimalParameters(); The "step" argument was a constant by which the computed step had to be multiplied, by default, it was 1. I know that this kind of writting is not as clear and lightweight as the current one, which is used by Matlab too. But perhaps giving more latitude to the user can be proposed with this system. If people want, I can try making a real Python example... Matthieu P.S. : sorry for the multiposting, I forgot that there were two ML for SciPy :(

9 40

ANN: SciPy 2007 Conference
by Travis Vaught April 17, 2007

April 17, 2007

Greetings, The *SciPy 2007 Conference* has been scheduled for mid-August at CalTech. http://www.scipy.org/SciPy2007 Here's the rough schedule: Tutorials: August 14-15 (Tuesday and Wednesday) Conference: August 16-17 (Thursday and Friday) Sprints: August 18 (Saturday) Exciting things are happening in the Python community, and the SciPy 2007 Conference is an excellent opportunity to exchange ideas, learn techniques, contribute code and affect the direction of scientific computing (or just to learn what all the fuss is about). Last year's conference saw a near-doubling of attendance to 138, and we're looking forward to continued gains in participation. We'll be announcing the Keynote Speaker and providing a detailed schedule in the coming weeks. Registration: ------------- Registration is now open. You may register online at https://www.enthought.com/scipy07. Early registration for the conference is $150.00 and includes breakfast and lunch Thursday & Friday and a very nice dinner Thursday night. Tutorial registration is an additional $75.00. After July 15, 2007, conference registration will increase to $200.00 (tutorial registration will remain the same at $75.00). 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(a)scipy.org -- the deadline for abstract submission is July 6, 2007. Papers and/or presentation slides are acceptable and are due by August 3, 2007. Tutorial Sessions ----------------- Last year's conference saw an overwhelming turnout for our first-ever tutorial sessions. In order to better accommodate the community interest in tutorials, we've expanded them to 2 days and are providing food (requiring us to charge a modest fee for tutorials this year). A tentative list of topics for tutorials includes: - Wrapping Code with Python (extension module development) - Building Rich Scientific Applications with Python - Using SciPy for Statistical Analysis - Using SciPy for Signal Processing and Image Processing - Using Python as a Scientific IDE/Workbench - Others... This is a preliminary list; topics will change and be extended. If you'd like to present a tutorial, or are interested in a particular topic for a tutorial, please email the SciPy users mailing list (link below). A current list will be maintained here: http://www.scipy.org/SciPy2007/Tutorials Coding Sprints -------------- We've dedicated the Saturday after the conference for a Coding Sprint. Please include any ideas for Sprint topics on the Sprints wiki page here: http://www.scipy.org/SciPy2007/Sprints We're looking forward to another great conference! Best, Travis ------------- Links to various SciPy and NumPy mailing lists may be found here: http://www.scipy.org/Mailing_Lists

1 0

Windows build with MSVC
by Albert Strasheim April 17, 2007

April 17, 2007

Hello all For lack of other sources of pain in my life, I'm giving the SciPy build with MSVC and G77 a go again. I've already fixed a few issues: http://projects.scipy.org/scipy/scipy/changeset/2927 http://projects.scipy.org/scipy/scipy/changeset/2928 I'm currently running into problems at building the scipy.special._cephes extension. I get the following error: cephes.lib(exp10.obj) : error LNK2001: unresolved external symbol _isnan cephes.lib(cbrt.obj) : error LNK2001: unresolved external symbol _isnan cephes.lib(unity.obj) : error LNK2019: unresolved external symbol _isnan referenced in function _cephes_expm1 cephes.lib(ndtr.obj) : error LNK2019: unresolved external symbol _isnan referenced in function _cephes_erfc cephes.lib(gamma.obj) : error LNK2001: unresolved external symbol _isnan cephes.lib(exp2.obj) : error LNK2001: unresolved external symbol _isnan build\lib.win32-2.4\scipy\special\_cephes.pyd : fatal error LNK1120: 1 unresolved externals It seems the cephes macro soup has gotten isnan wrong for the MSVC build. The MSDN docs for isnan are here: http://msdn2.microsoft.com/en-us/library/tzthab44(VS.80).aspx Maybe someone can figure out the right mix of defines and mconf.h magic to make it build again? Thanks! Regards, Albert

1 0

Scipy and LAPACK 3.1.* ?
by David Cournapeau April 12, 2007

April 12, 2007

Hi there, I tried to compile numpy/scipy with recent LAPACK and BLAS versions (LAPACK 3.1.1, BLAS from the netlib package, not from LAPACK, using gfortran as a compiler everywhere), and I got several errors when testing scipy: ====================================================================== FAIL: check_syevr (scipy.lib.tests.test_lapack.test_flapack_float) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/david/local/lib/python2.5/site-packages/scipy/lib/lapack/tests/esv_tests.py", line 41, in check_syevr assert_array_almost_equal(w,exact_w) File "/home/david/local/lib/python2.5/site-packages/numpy/testing/utils.py", line 230, in assert_array_almost_equal header='Arrays are not almost equal') File "/home/david/local/lib/python2.5/site-packages/numpy/testing/utils.py", line 215, in assert_array_compare assert cond, msg AssertionError: Arrays are not almost equal (mismatch 33.3333333333%) x: array([-0.66992444, 0.48769468, 9.18222618], dtype=float32) y: array([-0.66992434, 0.48769389, 9.18223045]) ====================================================================== FAIL: check_syevr_irange (scipy.lib.tests.test_lapack.test_flapack_float) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/david/local/lib/python2.5/site-packages/scipy/lib/lapack/tests/esv_tests.py", line 66, in check_syevr_irange assert_array_almost_equal(w,exact_w[rslice]) File "/home/david/local/lib/python2.5/site-packages/numpy/testing/utils.py", line 230, in assert_array_almost_equal header='Arrays are not almost equal') File "/home/david/local/lib/python2.5/site-packages/numpy/testing/utils.py", line 215, in assert_array_compare assert cond, msg AssertionError: Arrays are not almost equal (mismatch 33.3333333333%) x: array([-0.66992444, 0.48769468, 9.18222618], dtype=float32) y: array([-0.66992434, 0.48769389, 9.18223045]) ---------------------------------------------------------------------- The different dtype may suggest an error while compiling the BLAS/LAPACK, but I tested the libraries with official tester without any error. cheers, David

2 2

Re: [SciPy-dev] SciPy improvements
by Joe Harrington April 12, 2007

April 12, 2007

Just a comment on Robert's otherwise-excellent reply, we agreed some time ago that the forum for discussing changes to the site is this list, not trac. This is because many participants such as myself are not involved in code development and do not have (or need) trac accounts. We should *not* encourage people simply to romp in the pages and restructure as they please, as the web site is in constant public view by more than just developers and should therefore not be a playground for testing ideas (except for DevZone, which is specifically for that purpose). Shortly after the switch to the Moin site, someone went in and rewrote a bunch of the pages to follow their own style, and it made us realize that an open invitation to edit was not the best idea. Small changes like adding a link or an entry in a list are of course fine to make. Changing a page's overall structure should at least get a brief review by the list. The page layouts are simple enough that improvements can either be discussed based on a posted description, or actually made by example. For the latter, copy the page onto a page hanging off of DevZone and post an email pointing to it and asking for comment. For obvious reasons, the front page can only be modified by a few people, not just anyone with an account. It would be best if people making regular changes identified themselves in DevZone as site maintainers so that others can find them. That said, I agree restructuring is called for in some cases, and as Robert pointed out, in the doc area what's really needed is a doc. I think we'll be quick to cheer on anything reasonable in either area. --jh--

2 1

lmder patch
by Andy Jennings April 11, 2007

April 11, 2007

optimize.leastsq is not converging when I use a jacobian function. MATRIXC2F is transposing the wrong way. Below is a patch that fixes it in jac_multipack_lm_function, but I'm not sure this is the right fix. It looks like jac_multipack_calling_function might have the same problem, in which case maybe it's better to fix the definition of MATRIXC2F in Lib/optimize/minpack.h. I guess I would want a test case for hybrj to be sure. Lib/integrate/multipack.h and Lib/interpolate/multipack.h also define a MATRIXC2F macro. I have no idea if they need to be looked at as well. AJennings P.S. I just signed up for a trac account a few days ago. I have to submit patches to someone with the rights to commit, right? Is this scipy-dev list the best place to do it? Index: Lib/optimize/__minpack.h =================================================================== --- Lib/optimize/__minpack.h (revision 2901) +++ Lib/optimize/__minpack.h (working copy) @@ -149,7 +149,7 @@ return -1; } if (multipack_jac_transpose == 1) - MATRIXC2F(fjac, result_array->data, *n, *ldfjac) + MATRIXC2F(fjac, result_array->data, *ldfjac, *n) else memcpy(fjac, result_array->data, (*n)*(*ldfjac)*sizeof(double)); }

2 1