Mailman 3 April 2007 - SciPy-Dev

ctypes requirement?
by Matthew Brett April 11, 2007

April 11, 2007

Hi, I was thinking of using ctypes in some of the scipy matlab read / write routines. I noticed that a couple of sandbox packages are already using it. Does the team think the time has come for ctypes to be a requirement for scipy? It will make some development easier. Thanks, Matthew

2 1

eigh implementation inconsistency
by Robert Cimrman April 10, 2007

April 10, 2007

I need to solve a symmetric generalized eigenvalue problem, so I have looked at the linalg module and found a thing that seems inconsistent to me. For general (unsymmetric) problems there is the 'eig' function which allows for solving both the regular (via *geev) and generalized (via *ggev) eigenvalue problems. On the other hand, the function 'eigh' for symmetric (or hermitian) problems does not allow the generalized problems, even though there are functions in lapack to do it (dsygv, chegv). I would modify eigh to accept an optional 'b' argument just like eig does. What must be done to have dsygv, chegv wrappers generated? They are not generated now, IMHO. r.

4 6

UMFPACKv4.4 and swig memory leak of type 'void *'
by Nils Wagner April 10, 2007

April 10, 2007

Hi all, scipy.test(1,10) reports a lot of memory leaks, e.g. Getting factors of complex matrixswig/python detected a memory leak of type 'void *', no destructor found. Getting factors of real matrixswig/python detected a memory leak of type 'void *', no destructor found. Solve with UMFPACK: double precision complexswig/python detected a memory leak of type 'void *', no destructor found. swig/python detected a memory leak of type 'void *', no destructor found. ... ok Solve: single precision complexUse minimum degree ordering on A'+A. ... ok Solve with UMFPACK: double precisionswig/python detected a memory leak of type 'void *', no destructor found. swig/python detected a memory leak of type 'void *', no destructor found. ... ok Is this a swig problem ? I am using Numpy version 1.0.2.dev3562 Scipy version 0.5.3.dev2774 cat /proc/cpuinfo yields processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 15 model name : Intel(R) Core(TM)2 CPU 6300 @ 1.86GHz stepping : 6 cpu MHz : 1596.000 cache size : 2048 KB physical id : 0 siblings : 2 core id : 0 cpu cores : 2 fpu : yes fpu_exception : yes cpuid level : 10 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm syscall nx lm constant_tsc pni monitor ds_cpl vmx est tm2 cx16 xtpr lahf_lm bogomips : 3726.92 clflush size : 64 cache_alignment : 64 address sizes : 36 bits physical, 48 bits virtual power management: processor : 1 vendor_id : GenuineIntel cpu family : 6 model : 15 model name : Intel(R) Core(TM)2 CPU 6300 @ 1.86GHz stepping : 6 cpu MHz : 1596.000 cache size : 2048 KB physical id : 0 siblings : 2 core id : 1 cpu cores : 2 fpu : yes fpu_exception : yes cpuid level : 10 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm syscall nx lm constant_tsc pni monitor ds_cpl vmx est tm2 cx16 xtpr lahf_lm bogomips : 3724.17 clflush size : 64 cache_alignment : 64 address sizes : 36 bits physical, 48 bits virtual power management: amd_info: libraries = ['amd'] library_dirs = ['/usr/local/src/UMFPACKv4.4/AMD/Lib'] define_macros = [('SCIPY_AMD_H', None)] swig_opts = ['-I/usr/local/src/UMFPACKv4.4/AMD/Include'] include_dirs = ['/usr/local/src/UMFPACKv4.4/AMD/Include'] umfpack_info: libraries = ['umfpack', 'amd'] library_dirs = ['/usr/local/src/UMFPACKv4.4/UMFPACK/Lib', '/usr/local/src/UMFPACKv4.4/AMD/Lib'] define_macros = [('SCIPY_UMFPACK_H', None), ('SCIPY_AMD_H', None)] swig_opts = ['-I/usr/local/src/UMFPACKv4.4/UMFPACK/Include', '-I/usr/local/src/UMFPACKv4.4/AMD/Include'] include_dirs = ['/usr/local/src/UMFPACKv4.4/UMFPACK/Include', '/usr/local/src/UMFPACKv4.4/AMD/Include'] rpm -qi swig Name : swig Relocations: (not relocatable) Version : 1.3.29 Vendor: SUSE LINUX Products GmbH, Nuernberg, Germany Release : 29 Build Date: Mon 27 Nov 2006 10:46:51 PM CET Install Date: Mon 19 Feb 2007 09:04:53 AM CET Build Host: lanner.suse.de Group : Development/Languages/C and C++ Source RPM: swig-1.3.29-29.src.rpm Size : 3602040 License: BSD License and BSD-like Signature : DSA/SHA1, Mon 27 Nov 2006 10:57:29 PM CET, Key ID a84edae89c800aca Packager : http://bugs.opensuse.org URL : http://www.swig.org Summary : Simplified Wrapper and Interface Generator Nils

2 3

Deadline for scipy release 0.5.3
by Nils Wagner April 10, 2007

April 10, 2007

Hi all, I was wondering if there is a deadline for the next scipy release ? Nils

1 0

Re: [SciPy-dev] [Numpy-discussion] Tuning sparse stuff in NumPy
by Robert Cimrman April 10, 2007

April 10, 2007

David Koch wrote: > Ok, > > I did and the results are: > csc * csc: 372.601957083 > csc * csc: 3.90811300278 a typo here? which one is csr? > csr * csc: 15.3202679157 > csr * csr: 3.84498214722 > > Mhm, quite insightful. Note, that in an operation X.transpose() * X, > where X > is csc_matrix, then X.tranpose() is automatically cast to csr_matrix. A > re-cast to csc make the whole operation faster. It's still about 1000 times > slower than Matlab but 4 times faster than before. ok. now which version of scipy (scipy.__version__) do you use (you may have posted it, but I missed it)? Not so long ago, there was an effort by Nathan Bell and others reimplementing sparsetools + scipy.sparse to get better usability and performance. My (almost latest) version is 0.5.3.dev2860. r.

2 2

mlabwrap scikit [Was: Re: scikits project]
by Alexander Schmolck April 10, 2007

April 10, 2007

[Second attempt to move this to scipy-dev, this time using the right email account; for those who have no idea what mlabwrap is about: it's a python to matlab bridge currently on the move from sourceforge to scipy's emerging scikits infrastructure] Hi, First, it's great that mlabwrap has found a new home at scipy.org, big thanks to everyone involved. I'm afraid that I'm still not quite up to speed on all infrastructural issues -- I've not used subversion before and I haven't completely grokked the scipy infrastructure yet (although I've been trying to read up, especially on svn) and I'm a bit puzzled by some things (see below), so please excuse if some of what follows sounds a bit clueless. In order to bring the mlabwrap project forward, there are three things I'd like to achieve in the immediate future (by end of next week): 1. Resolve remaining infrastructural questions 2. Bring out mlabwrap-1.0 final 3. Discuss a roadmap and feature requirements for mlabwrap 2.0 So let's start out with 1. : ---------------------------- "Jarrod Millman" <millman(a)berkeley.edu> writes: > Hey, > > Jeff got everything setup and I tested it out. Everything looks good > (Thanks Jeff and Robert!). > > I checked in mlabwrap v1.0b: > https://projects.scipy.org/scipy/scikits/browser/trunk/mlabwrap > And then since Jeff installed the rest macro; I added > [[ReST(/trunk/mlabwrap/README.txt)]] > which Trac renders like this: > https://projects.scipy.org/scipy/scikits/wiki/MlabWrap > I also moved the discussion about proxy objects from the NIPY site: > https://projects.scipy.org/scipy/scikits/wiki/MlabProxyObjects > > Hopefully everyone has access to the scikits subversion repository > now. If not, please try and get access ASAP. Shouldn't having a svn account mean that I'd be able to succesfully log in to the trac interface at <https://projects.scipy.org/scipy/scikits/browser/trunk/mlabwrap> using the same account? I can't either use the AlexanderSchmolck login I created on scipy.org, nor the POP3/SVN login a.schmolck(a)gmail.com[1] I received an email from webmin(a)scipy.org on Friday[3]; however I *can* commit to the repository using svn (I've sent an email to webmin(a)scipy.org, but haven't heard anything back). Another thing I've been wondering about is whether it would be easy to import the existing CVS repository into svn? I've fiddled around a little bit with cvs2svn and on first sight it looks like it migh work OK. Loosing the project history wouln't be too tragic (and I can just try to get the sf staff to upload the old CVS repository on the sf page, so it's publically available somewhere), but if we can just import the existing repository without too much of a hassle, I think this might be the best option. Before doing anything with the CVS repository, I'd first manually adapt the directory structure, though, bringing us to 1.a. source code and svn organization ''''''''''''''''''''''''''''''''''''' In an email some time ago Robert Kern proposed the following directory structure for scikits: branches/ tags/ trunk/ mlabwrap/ setup.py scikits/ __init__.py mlabwrap/ __init__.py The current directory structure misses the scikits/ dir and the second mlabwrap/ dir; instead it has mlabwrap.py at top-level (as well as the utility libraries awmstools.py and awmsmeta.py and the c++-extension mlabraw.cpp). Independent of scikits conventions, it seems that making mlabwrap a package and stuffing everything it needs inside (i.e. the utility libs and mlabraw) rather than polluting the toplevel module-namespace seems desirable I assume this question reflects my svn-newbie status, but why doesn't the scikits structure look something like this, given that as I understand it scikits are meant to be essentially independent (and hence independely versioned) projects under a common namespace? mlabwrap/ branches/ tags/ trunk/ setup.py scikits/ __init__.py mlabwrap/ __init__.py some_other_scikit/ branches/ ... It somehow seems to me that tags and branches should apply to individual projects and that one could still do convenient releases and svn-checkouts of scikits/ as a whole by using e.g. svn:externals to the individual projects. As I said, I'm not really knowledgable about svn, but I'd like to understand the logic a bit better, because I'm also trying to work out what to do about the awmsmeta.py and awmstools.py stuff, which isn't really a part of mlabwrap as such. I see three ways of dealing with the dependency on the utility modules: D1. Drop it and copy-and-paste the needed bits into mlabwrap.py (certainly possible, only a few functions are needed; OTOH it seems a bit ugly) D2. Rely on cheeseshop (but I don't have the impression that it is equally acceptable and painless for a python module to download and install dependencies as it is for a CTAN module) D3. Stuff copies into mlabwrap/ and do a relative import D3. seems most attractive to me at the moment but one would still have to figure out where the VC of awmstools.py and awmsmeta.py would "live"; I thought it would be cleanest if they were included as svn:externals and not directly part of the mlabwrap svn tree, so I thought maybe something like this (ignoring the question of where branches/ trunk/ and tags/ go exactly): mlabwrap/ setup.py scikits/ __init__.py README.txt # etc. mlabraw.py # dummy importing mlabwrap/mlabraw, for backwards comp. mlabwrap/ __init__.py -> awmstools.py -> awmsmeta.py mlabwraw.cpp test/ test_mlabwrap.py # etc. I also assume we want a branch for the 1.0.x version, a tag for the 1.0 release (when it's ready) and that development of the next version will continue in the trunk. Comments? Also are there any strong feelings/established procedures concerning __init__.py? The generic name is somewhat inconvient in various contexts (e.g. buffer switching im emacs) so I thought about making __init__.py a dummy importing ./_mlabwrap.py or so. OK, sorry this is getting so long, on to 2. bringing out mlabwrap-1.0 final: ------------------------------------ Apart from the question what the directory structure should look like, the only issue that I'm currently aware of is that there appears to be a problem with `setup.py` automatically finding out about the matlab version under windows; if no one steps up to do some windows testing I'm also willing to apply some fix I assume will work and release as is (windows users might have to set MATLAB_VERSION etc. in setup.py by hand if it doesn't, which isn't *that* terrible). Actually, one more thing: distutils vs. scipy distutils vs. setuptools -- which one should mlabwrap-1.0 final use? I'm only really fully familiar with the first one. Finally point 3, the road-map: ------------------------------ I'd like to get some idea what is felt as needed for the next version of mlabwrap (let's say 2), by when (e.g. because it would be really handy for NIPY; how important is e.g. that 'proxy.a.b = c' works as expected?) and who is interested on working on specific parts (like the move to ctypes). Also what python and matlab versions should mlabwrap 2 have to support? How should changes affecting backwards compatibility best be handled (maybe allowing getting v1 default behavior with something like `from mlabwrap.v1 import mlab`?)? I've put up some notes concerning mlabwrap development and design issues at <http://www.scipy.org/MlabWrap>, corrections, additions and feedback (using either the wiki page itself or scipy-dev) are highly welcome. Sorry for the relative long silence -- apart from hacking on the next version, writing up my thoughts and wikifying took *far* longer than I would have thought, especially since it's only personal note-quality rather than something polished. I hope it's at least partly intelligible and useful. cheers, 'as Footnotes: [1] Are those two account logins meant to be different or is this just because I was too dumb to notify Jeff Strunk of my newly created scipy.org account in time? BTW unless there's some convention that the svn login should be an email address, I'd rather just have a.schmolck (sans gmail.com), if it's something that's easy to change.

6 16

scipy.test "generic 1d filter" crashes interpreter on windows
by Brett Olivier April 4, 2007

April 4, 2007

Hi Running scipy.test() after installing an SVN version of scipy on windows ('0.5.3.dev2895') causes the interpereter to crash on the "generic 1d filter" test. This problem seems to be windows specific and have appeared sometime after '0.5.3.dev2866'. scipy.test(1,10) generation of a binary structure 3 ... ok generation of a binary structure 4 ... ok generic filter 1 ... ERROR generic 1d filter 1 Build environment scipy.__version__ = '0.5.3.dev2895' numpy.__version__ = '1.0.3.dev3657' WinXP, Python2.4, MinGW (gcc 3.4.5), ATLAS 3.7.11 TIA Brett

2 1

NumPy 1.0.2 released
by Travis Oliphant April 3, 2007

April 3, 2007

To all SciPy / NumPy users: NumPy 1.0.2 was released yesterday (4-02-07). Get it by following the download link at http://numpy.scipy.org This is a bug-fix release with a couple of additional features. Thanks to everybody who helped track down and fix bugs. -Travis

1 0

Improving scipy.clusters
by David Cournapeau April 3, 2007

April 3, 2007

Hi there, I would like to clean-up and improve the kmean algorithm (more initialization schemes for the algorithm, and better docs). I already have write access to the scipy svn rep, but as scipy.clusters is not in the sandbox nor my code, I would like to make sure it is OK, cheers, David

3 2

Violation of array scalar multiplication rules?
by Charles R Harris April 1, 2007

April 1, 2007

Just asking. In [35]: type(array(1.0)*2) Out[35]: <type 'numpy.float64'> In [36]: type(array(1.0)) Out[36]: <type 'numpy.ndarray'> Chuck

1 0