Mailman 3 March 2006 - SciPy-Dev

Fortran type objects
by cookedm＠physics.mcmaster.ca March 3, 2006

March 3, 2006

I think scipy should define some fortran scalar types: fint, fsingle, fdouble, etc. One reason for this is that I believe (don't quote me) is that sizeof(INTEGER) == 4 on my 64-bit machine in g77. This means arrays passed to Fortran code (through f2py, for instance), should be have a dtype of 'i4', not 'i8', which is what int would give. >From a documentation standpoint, this is also useful. I don't know, however, how to code up a test for how large these types are. -- |>|\/|< /--------------------------------------------------------------------------\ |David M. Cooke http://arbutus.physics.mcmaster.ca/dmc/ |cookedm(a)physics.mcmaster.ca

1 0

Patch fixing problems in integrate/ode.py for banded systems
by Jesper Friis March 3, 2006

March 3, 2006

Here is a small patch (just 2 lines) that enters the size of the upper and lower diagonals in the work arrays before calling DVODE. Without this patch DVODE will return immediately, complaining about illegal input. Another minor problem with the interface to DVODE is that the function calculating the Jacobian is expected to return a matrix of size NROWPD by len(y), where NROWPD unfortunately is not provided as an argument to the Jacobian function in the python interface. For trigonal systems NROWPD is e.g. 4 and not 3 as one would expect. On the other hand is an error message is printed when a matrix of the wrong size is returned, so this problem is easy to fix... --- scipy-0.4.6/Lib/integrate/ode.py.org 2006-03-03 13:20:36.000000000 +0100 +++ scipy-0.4.6/Lib/integrate/ode.py 2006-03-03 16:17:17.000000000 +0100 @@ -337,6 +337,8 @@ rwork[6] = self.min_step self.rwork = rwork iwork = zeros((liw,),'i') + if self.ml != None: iwork[0] = self.ml + if self.mu != None: iwork[1] = self.mu iwork[4] = self.order iwork[5] = self.nsteps iwork[6] = 2 # mxhnil

2 1

Kuipers statistics
by Manuel Metz March 3, 2006

March 3, 2006

Hi, I have attached a patch for the file /Lib/special/cephes/kolmogorov.c. This patch adds a function 'kuiper(y)' which is very similar to the function 'kolmogorov(y)', which is required for the K-S-Test. Kuipers statistics is a variant of K-S statistics which is invariant on a circle. I did not write an inverse function yet (is't not monotonic in it's first derivative) and also did not include patches for the corresponding .py files. Is there any interest to include the Kuiper statistics into SciPy ??? Manuel

2 2

Stats t-test broken on 1D input
by Zachary Pincus March 2, 2006

March 2, 2006

Hi folks, Sorry to re-post, but nobody in scipy-user seemed too concerned that the most basic form of the most basic statistical test -- the T-test on 1D input -- is broken in scipy 0.4.6. In [1]: import scipy.stats In [2]: scipy.version.version Out[2]: '0.4.6' In [3]: scipy.stats.ttest_ind([1,2,3],[1,2,3]) TypeError: len() of unsized object In [4]: scipy.stats.ttest_rel([1,2,3],[1,2,3]) TypeError: len() of unsized object The problem is at lines 1463 and 1512 of stats.py, where len() is applied to a scalar result. This can be fixed by chainging the blocks that look like: if type(t) == ArrayType: probs = reshape(probs,t.shape) if len(probs) == 1: probs = probs[0] to look like: if type(t) == ArrayType: probs = reshape(probs,t.shape) if len(probs) == 1: probs = probs[0] That is, probs is guaranteed to be a scalar ( I think) if t is not an array. I assume that in a previous version of scipy this was not the case, but now it is. Zach Pincus Program in Biomedical Informatics and Department of Biochemistry Stanford University School of Medicine

4 5

Segmentation fault
by Nils Wagner March 2, 2006

March 2, 2006

I tried to track down the problem with scipy.test(1,10). I changed the lower and upper limits of the integrals by accident. Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 16384 (LWP 15072)] 0x00002aaab17fdc25 in dqc25f_ () from /usr/lib64/python2.4/site-packages/scipy/integrate/_quadpack.so (gdb) bt #0 0x00002aaab17fdc25 in dqc25f_ () from /usr/lib64/python2.4/site-packages/scipy/integrate/_quadpack.so #1 0x00002aaab17f9b64 in dqawoe_ () from /usr/lib64/python2.4/site-packages/scipy/integrate/_quadpack.so #2 0x00002aaab17f0552 in quadpack_qawoe (dummy=<value optimized out>, args=<value optimized out>) at __quadpack.h:420 #3 0x00002aaaaac5496a in PyEval_EvalFrame (f=0x774bf0) at ceval.c:3547 #4 0x00002aaaaac53b97 in PyEval_EvalFrame (f=0x8ac7b0) at ceval.c:3629 #5 0x00002aaaaac55404 in PyEval_EvalCodeEx (co=0x2aaaae039c70, globals=<value optimized out>, locals=<value optimized out>, args=0xb, argcount=3, kws=0x5066a8, kwcount=3, defs=0x2aaaae0570f8, defcount=11, closure=0x0) at ceval.c:2730 #6 0x00002aaaaac53aba in PyEval_EvalFrame (f=0x506500) at ceval.c:3640 #7 0x00002aaaaac55404 in PyEval_EvalCodeEx (co=0x2aaaaab23c70, 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=0x7fffffbbfb50 "quadtest", co=0x2aaaaab23c70, pathname=<value optimized out>) at import.c:619 Nils

1 0

Program exited with code 012
by Nils Wagner March 2, 2006

March 2, 2006

Hi all, The latest attempt to install numpy/scipy with ATLAS support on a 64 bit machine works but scipy.test(1,10) results in check_y_stride (scipy.linalg.tests.test_fblas.test_zswap) ... ok check_algebraic_log_weight (scipy.integrate.tests.test_quadpack.test_quad) ... ok check_cauchypv_weight (scipy.integrate.tests.test_quadpack.test_quad) ... ok check_cosine_weighted_infinite (scipy.integrate.tests.test_quadpack.test_quad)STOP 778 Program exited with code 012. (gdb) bt No stack. I have never observed such an error before. Google http://doc.bughunter.net/format-string/format-bugs.html Is there any alternative to ATLAS ? Can I use ACML ? What is necessary to use the ACML within numpy/scipy ? Nils cat /proc/cpuinfo yields processor : 0 vendor_id : AuthenticAMD cpu family : 15 model : 47 model name : AMD Athlon(tm) 64 Processor 3200+ stepping : 2 cpu MHz : 2000.141 cache size : 512 KB fpu : yes fpu_exception : yes cpuid level : 1 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 syscall nx mmxext fxsr_opt lm 3dnowext 3dnow pni lahf_lm bogomips : 4009.73 TLB size : 1024 4K pages clflush size : 64 cache_alignment : 64 address sizes : 40 bits physical, 48 bits virtual power management: ts fid vid ttp tm stc

1 0

some sparse errors
by Arnd Baecker March 1, 2006

March 1, 2006

Hi, I just updated my numpy/scipy installation and get some errorrs Out[2]: '0.4.7.1625' In [3]: scipy.test(1) import io -> failed: invalid syntax (sparse.py, line 2119) [...] Warning: FAILURE importing tests for <module 'scipy.sparse' from '...ages/scipy/sparse/__init__.pyc'> /home/abaecker/NBB/SOFTWARE/morepub/pub_scipy/lib/python2.3/site-packages/scipy/sparse/tests/test_sparse.py:23: ImportError: cannot import name csc_matrix (in ?) Note that I am running python 2.3.5 sparse/sparse.py", line 2119 return sum(len(rowvals) for rowvals in self.vals) ^ SyntaxError: invalid syntax This looks like it is some 2.4 syntax being used ? Best, Arnd

4 5

Re: [SciPy-dev] [SciPy-user] New sparse matrix functionality
by Robert Cimrman March 1, 2006

March 1, 2006

>>Do you also plan to add the c-based linked-list matrix as in PySparse >>(ll_mat.c there)? This could be even faster than using the Python >>lists >>(IMHO...). > > > Well, I guess it would be nice to have, and the code's already > written, but I don't know how we'd make it derive from the spmatrix > base class, which is written in Python. Travis mentioned back in > October that this is possible but not easy. So it would require some well, we might eventually write a llmat class in Python that will 'borrow' (and appreciate, of course ;-)) relevant ll_mat functions - we do not need the ll_mat Python object. I can live without it for now, though :-) > work. I don't need the extra speed personally -- the new class seems > to be fast enough for my needs (the bottleneck for my work is now > elsewhere :) OK, I see... Can you tell me where? Just curious :-) > An update: I've changed the matrix.__mul__ function in NumPy SVN to > return NotImplemented if the right operand defines __rmul__ and isn't > a NumPy-compatible type. This seems to work fine for * now. > Functions like numpy.dot() still won't work on sparse matrices, but I > don't really have a problem with this ;) Fine with me... In the meantime, I have added a rudimentary umfpack support to the sparse module - it is used when present by 'solve' (and can be switched off). I have also fixed the umfpack module in the sandbox for complex matrices. (At least I hope so :)) Still, the umfpack must be installed separately, doing the classical 'python setup.py install' in its sandbox home, because I am still struggling with a proper system_info class to detect the umfpack libraries in the system. Any help/ideas would be appreciated. r.

1 0