Mailman 3 March 2006 - SciPy-Dev

Fwd: Re: CSparse license
by Alan G Isaac March 6, 2006

March 6, 2006

I hesitate to speak to this, but I am willing to convey the developer view back to Tim Davis. Alan Isaac ------ Forwarded message ------ From: Tim Davis <davis(a)cise.ufl.edu> Date: Mon, 06 Mar 2006 11:36:30 -0500 Subject: Re: CSparse license To: Alan Isaac <aisaac(a)american.edu> CSparse uses LGPL, not GPL. Isn't that compatible with SciPy? -------- End of message -------

2 1

0.9.6.2201 NameError: global name 'pi' is not defined
by Nils Wagner March 6, 2006

March 6, 2006

Traceback (most recent call last): File "<stdin>", line 1, in ? File "/usr/local/lib/python2.4/site-packages/numpy/__init__.py", line 46, in test return NumpyTest().test(level, verbosity) File "/usr/local/lib/python2.4/site-packages/numpy/testing/numpytest.py", line 422, in test suites.extend(self._get_module_tests(module, abs(level), verbosity)) File "/usr/local/lib/python2.4/site-packages/numpy/testing/numpytest.py", line 362, in _get_module_tests return self._get_suite_list(test_module, level, module.__name__) File "/usr/local/lib/python2.4/site-packages/numpy/testing/numpytest.py", line 377, in _get_suite_list suite = obj(mthname) File "/usr/local/lib/python2.4/site-packages/numpy/core/tests/test_ma.py", line 17, in __init__ self.setUp() File "/usr/local/lib/python2.4/site-packages/numpy/core/tests/test_ma.py", line 20, in setUp x=numpy.array([1.,1.,1.,-2., pi/2.0, 4., 5., -10., 10., 1., 2., 3.]) NameError: global name 'pi' is not defined

2 1

Bug w.r.t. Addition of sparse matrices
by Nils Wagner March 6, 2006

March 6, 2006

The addition of sparse matrices results in wrong results (see add.py for details). Nils

2 4

Another segfault
by Nils Wagner March 6, 2006

March 6, 2006

Hi all, I have no idea why this test results in a segfault. Maybe its a compiler issue ? (g77 versus gfortran) I have installed numpy/scipy via python setup.py config_fc --fcompiler=gnu95 install >>> import sparse_test.py Use minimum degree ordering on A'+A. Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 16384 (LWP 2632)] 0x00002aaab23e50b3 in dpivotL (jcol=0, u=1, usepr=0x7fffffb2a204, perm_r=0xa0fa40, iperm_r=0x816b50, iperm_c=0x9ffed0, pivrow=0x7fffffb2a210, Glu=0x9a0ac0, stat=0xffffffffab80bb68) at dpivotL.c:120 120 perm_r[*pivrow] = jcol; (gdb) bt #0 0x00002aaab23e50b3 in dpivotL (jcol=0, u=1, usepr=0x7fffffb2a204, perm_r=0xa0fa40, iperm_r=0x816b50, iperm_c=0x9ffed0, pivrow=0x7fffffb2a210, Glu=0x9a0ac0, stat=0xffffffffab80bb68) at dpivotL.c:120 #1 0x00002aaab23dadd0 in dgstrf (options=<value optimized out>, A=0x7fffffb2a330, drop_tol=<value optimized out>, relax=<value optimized out>, panel_size=10, etree=<value optimized out>, work=<value optimized out>, lwork=10549824, perm_c=0x945350, perm_r=0xa0fa40, L=0x2aaab508c7d0, U=0x2aaab508c7f0, stat=0x7fffffb2a310, info=0x7fffffb2a35c) at dgstrf.c:310 #2 0x00002aaab23bdb4b in newSciPyLUObject (A=0x7fffffb2a3f0, diag_pivot_thresh=1, drop_tol=0, relax=1, panel_size=10, permc_spec=2, intype=<value optimized out>) at _superluobject.c:372 #3 0x00002aaab23bc9ba in Py_dgstrf (self=<value optimized out>, args=<value optimized out>, keywds=<value optimized out>) at _dsuperlumodule.c:187 #4 0x00002aaaaac5496a in PyEval_EvalFrame (f=0xace630) at ceval.c:3547 #5 0x00002aaaaac55404 in PyEval_EvalCodeEx (co=0x2aaaae7e01f0, globals=<value optimized out>, locals=<value optimized out>, args=0x5, argcount=1, kws=0x506698, kwcount=0, defs=0x2aaaae7cef08, defcount=5, closure=0x0) at ceval.c:2730 #6 0x00002aaaaac53aba in PyEval_EvalFrame (f=0x506500) at ceval.c:3640 #7 0x00002aaaaac55404 in PyEval_EvalCodeEx (co=0x2aaaaab23b90, globals=<value optimized out>, locals=<value optimized out>, args=0x0, argcount=0, kws=0x0, kwcount=0, defs=0x0, defcount=0, closure=0x0) at ceval.c:2730 #8 0x00002aaaaac556d2 in PyEval_EvalCode (co=<value optimized out>, globals=<value optimized out>, locals=<value optimized out>) at ceval.c:484 #9 0x00002aaaaac67cc7 in PyImport_ExecCodeModuleEx (name=0x7fffffb2b370 "sparse_test", co=0x2aaaaab23b90, pathname=<value optimized out>) at import.c:619 #10 0x00002aaaaac68e3d in load_source_module (name=0x7fffffb2b370 "sparse_test", pathname=0x7fffffb2aeb0 "sparse_test.py", fp=<value optimized out>) at import.c:893 #11 0x00002aaaaac6a854 in import_submodule (mod=0x2aaaaadbee30, subname=0x7fffffb2b370 "sparse_test", fullname=0x7fffffb2b370 "sparse_test") at import.c:2250 #12 0x00002aaaaac6aa72 in load_next (mod=0x2aaaaadbee30, altmod=0x2aaaaadbee30, p_name=<value optimized out>, buf=0x7fffffb2b370 "sparse_test", p_buflen=0x7fffffb2b78c) at import.c:2070 #13 0x00002aaaaac6af07 in PyImport_ImportModuleEx (name=0x2aaaaaae0360 "\002", globals=0x2aaaaaae0384, locals=<value optimized out>, fromlist=0x2aaaaadbee30) at import.c:1905 #14 0x00002aaaaac47d73 in builtin___import__ (self=<value optimized out>, args=<value optimized out>) at bltinmodule.c:45 Any suggestion how to resolve this problem ? Nils

7 26

broken scipy.optimize.anneal
by Tim Leslie March 6, 2006

March 6, 2006

Hi all, I posted to scipy-users earlier today asking about using multiple parameters with scipy.optimize.anneal. After fiddling with the code for a while to get it to work I've decided that the whole module is fairly broken. pylint and pychecker showed up a number of unused variables and imports, reading the code led me to missing imports, uncommenting the test code in the __main__ section caused breakage and there are any number of problems if you try to use multiple parameters for your function :-) I've started work on fixing all these issues, I was wondering if anyone on the list wanted to claim rights over this module and have a say in any of the changes that might happen. The comments at the top of the file claim: ## Automatically adapted for scipy Oct 07, 2005 by convertcode.py # Author: Travis Oliphant 2002 If noone has any objections I'll open a ticket and submit a patch when I'm done. Cheers, Tim

1 1

Extensions linking to libraries used by numpy/scipy
by Tom Loredo March 6, 2006

March 6, 2006

Hi folks, I asked about this some time ago and was told there was no straightforward way to accomplish it, but that was over a year ago and before the recent numpy/scipy split, etc.. So I thought I'd ask again. I'm writing a package with several C and Fortran extensions, some of which call functions or subroutines that do things already done by Scipy routines, e.g., evaluate a gamma function, perform an LU decomposition, etc.. There are repeated calls, in the course of a more complex calculation, and the most sensible way to do the calculations would be to call Scipy's library routines directly, and not go back through Python. In some cases as a placeholder I have a version derived from Numerical Recipes, and this is a no-no as far as public distribution is concerned. I'd like to be able to call & link to the C or Fortran libraries that Scipy is accessing, but I need to do it in a way that will build and operate reliably across the various platforms Scipy builds on. As specific examples, I'd like to access functions in cephes/gamma.c, and lapack routines for LU decomposition and determinant calcuation, e.g., DGETRF, DGBTRF or DGTTRF. I suspect this isn't hard for gamma.c, but since Scipy is sometimes built with BLAS/LAPACK, and sometimes with ATLAS, I suspect it's harder for the LU decomposition. So... is there a way to do this portably? If so, is it documented somewhere (example code and an example setup.py)? Are there examples I could look at? Do some particular Scipy modules provide good examples of this (which ones)? Thanks for any pointers, Tom ------------------------------------------------- This mail sent through IMP: http://horde.org/imp/

2 1

KeyError: ('d', 'l')
by Nils Wagner March 4, 2006

March 4, 2006

x0,info = linalg.cgs(A,r) File "/usr/local/lib/python2.4/site-packages/scipy/linalg/iterative.py", line 465, in cgs typ = _coerce_rules[b.dtype.char,atyp] KeyError: ('d', 'l') >>> A array([[1, 0, 0, 0], [0, 1, 0, 0], [0, 0, 1, 0], [0, 0, 0, 1]]) >>> r array([ 0.61542588, 0.53775049, 0.29953529, 0.50247666]) >>> type(A) <type 'numpy.ndarray'> A is defined as A = identity(4)

1 0

Iterative solvers cannot handle complex rhs
by Nils Wagner March 4, 2006

March 4, 2006

x0,info = linalg.cgs(A,r) File "/usr/local/lib/python2.4/site-packages/scipy/linalg/iterative.py", line 474, in cgs b = sb.asarray(b,typ) File "/usr/local/lib/python2.4/site-packages/numpy/core/numeric.py", line 74, in asarray return array(a, dtype, copy=False, fortran=fortran, ndmin=ndmin) TypeError: array cannot be safely cast to required type >>> type(A) <type 'instance'> >>> shape(A) (4, 4) >>> A <4x4 sparse matrix of type '<type 'float64scalar'>' with 4 stored elements (space for 100) in Compressed Sparse Column format> >>> r array([ 0.87207973+0.45474362j, 0.41920682+0.12267298j, 0.59096886+0.53802559j, 0.3652316 +0.86013843j]) >>> type(r) <type 'numpy.ndarray'> >>> shape(r) (4,) Nils

1 0

Bug in linalg.cgs
by Nils Wagner March 4, 2006

March 4, 2006

x0,info = linalg.cgs(A,r) File "/usr/local/lib/python2.4/site-packages/scipy/linalg/iterative.py", line 501, in cgs work[slice2] += sclr1*matvec(work[slice1]) ValueError: invalid return array shape >>> A matrix([[ 1., 0., 0., 0.], [ 0., 1., 0., 0.], [ 0., 0., 1., 0.], [ 0., 0., 0., 1.]]) >>> r array([ 0.17858324, 0.42785877, 0.48033897, 0.85571193]) >>> help (linalg.cgs) >>> shape(r) (4,) >>> shape(A) (4, 4) >>> type(A) <class 'numpy.core.defmatrix.matrix'> >>> type(r) <type 'numpy.ndarray'>

1 0

numpy.linalg prevents use of scipy.linalg?
by Zachary Pincus March 4, 2006

March 4, 2006

Hi folks, I can't seem to use any of the functions in scipy.linalg because numpy defines its own linalg which shadows that of scipy! Specifically, scipy.linalg defines 'norm' (in linalg/basic.py), and numpy doesn't. (This among other differences, I assume.) In [1]: import scipy In [2]: scipy.linalg.norm AttributeError: 'module' object has no attribute 'norm' In [3]: scipy.linalg.__file__ Out[3]: '[...]/python2.4/site-packages/numpy/linalg/__init__.pyc' ^^^^^^^ Now, look what happens when we import scipy.linalg directly: In [1]: import scipy.linalg In [2]: scipy.linalg.norm Out[2]: <function norm at 0x14261f0> In [3]: scipy.linalg.__file__ Out[3]: '[...]/python2.4/site-packages/scipy/linalg/__init__.pyc' ^^^^^^^ Something needs to be done to fix this -- but what? Scipy historically imports * from numpy. Scipy historically has a linalg module. The new thing is that numpy has a linalg module, too, which is loaded by default into the numpy namespace. (Compared to Numeric's LinearAlgebra module.) The only thing I can think of is to fold all of scipy.linalg into numpy.linalg, and remove the former. This provides for backwards compatibility for everyone, but perhaps a bit of work. Zach

5 7