Mailman 3 May 2005 - SciPy-Dev

IDL to Python converter available
by Christopher Stawarz May 30, 2005

May 30, 2005

I've written a package, i2py, that converts IDL scripts and programs to Python. It started as a project for the compilers class I took this spring, and in the weeks since I've cleaned it up and improved it enough that I think it's ready for an alpha release. Since there was recently a discussion on this list about this sort of thing, I expect some people will be interested in trying it out. The package is implemented in pure Python and requires Python 2.3 or later. Using PLY (which is included in the distribution), it implements a full-fledged parser for procedural IDL (no OO support yet) and can convert most (but not yet all) IDL language constructs to Python. More information on it, including some notes on its current limitations and a brief introductory tutorial, can be found at http://software.pseudogreen.org/i2py/ Source packages are available for download from ftp://pseudogreen.org/pub/i2py/ If you'd like to try it out, I'd definitely appreciate any feedback. (If there's a lot of interest, I may move the project to SourceForge or somewhere similar, but I'll have to see what happens.) Since the scipy-dev thread I mentioned earlier was mainly about the legal issues surrounding this kind of software, I think I should address those a bit. First, I should make it clear that I've developed i2py entirely on my own time, using my own resources. However, since I am a full-time programmer at an astronomical research institute and have, on a few occasions, used IDL as part of my job, I thought it wise to discuss the potential issues with my employers before releasing the package. The conclusion reached in that discuss was that, although IDL's EULA explicitly forbids reverse engineering, implementing a parser and converter for the language does *not* constitute reverse engineering, because it requires only the published, publicly-available description of the language. (Similarly, if I use Visual C++ and then go buy Stroustrup's book and write my own C++ compiler, my actions don't constitute reverse engineering, because anything I might learn about C++ from using VC++ can also be learned from the book.) Hence, I feel quite confident that my development of i2py has neither violated the IDL EULA nor infringed upon RSI's intellectual property rights in any way. Of course, if you think otherwise, then you shouldn't use the package. Anyway, I hope some of you will find i2py useful, and I look forward to the chance to improve it based on your feedback. Thanks, Chris Stawarz

1 0

patch for scipy_base.diag
by p.berkes＠biologie.hu-berlin.de May 26, 2005

May 26, 2005

Hi! There is a casting problem in the 'diag' function: >>> a = scipy.array([1,2,3], 'f') >>> scipy.diag(a).typecode() >>> 'd' while it should be 'f'. The function can be easily patched (only the calls to eye are modified): In file: /home2/scipy/local/lib/python2.3/site-packages/scipy_base/matrix_base.py def diag(v, k=0): """ returns the k-th diagonal if v is a matrix or returns a matrix with v as the k-th diagonal if v is a vector. """ v = asarray(v) s = v.shape if len(s)==1: n = s[0]+abs(k) if k > 0: v = concatenate((zeros(k, v.typecode()),v)) elif k < 0: v = concatenate((v, zeros(-k, v.typecode()))) return eye(n, k=k, typecode=v.typecode())*v elif len(s)==2: v = add.reduce(eye(s[0], s[1], k=k, typecode=v.typecode())*v) if k > 0: return v[k:] elif k < 0: return v[:k] else: return v else: raise ValueError, "Input must be 1- or 2-D." Best, Pietro.

1 0

On entry to DGESDD parameter number 12 had an illegal value
by Nils Wagner May 20, 2005

May 20, 2005

Hi all, Can someone reproduce the following error ? scipy.test(1,verbosity=10) ... check_random (scipy.linalg.decomp.test_decomp.test_svd) ** On entry to DGESDD parameter number 12 had an illegal value Parameter number 12 is connected with LWORK. Any idea ? Nils

2 3

Re: Numeric 3 status
by Travis Oliphant May 19, 2005

May 19, 2005

Eric Jonas wrote: >>I forgot to let you know in my previous email, that I would be very, >>very pleased to receive help on scipy.base. There is a great deal of >>opportunity for people to get involved and assist with the formation of >>a solid scipy.base. I listed a few areas in my previous email, but I'm >>sure I forgot some things. >> >> > >Well, I have an undergraduate working with me with some decent C and >python experience and an interest in numerical computing; we've >downloaded the latest from the SF CVS Numeric3 module and are going to >start looking over things; are there any mailing lists or other >recommended sources of information? As the person in charge of all of >this, is there some area you'd prefer for us to get started on ? We'd >love to help you get this all working this summer... > ...Eric > > I forgot to mention that there are a couple of other projects that are more Python-related that would also be important long term and could easily be handled by an undergraduate: 1) Changing Python pickle code so that a buffer object can be pickled directly (without first copying to a string). -- It would be nice to have a better buffer object which has been discussed ad nausem on python-dev, but this simple addition would add a great deal of functionality. -- It might be coupled with a way to get an empty buffer object from Python (i.e.) buffer(1024) would construct an empty writeable buffer of 1024 bytes (you can do this with the Python C-API, but it is not exposed to the Python Interpreter). 2) Adding the __asindex__ method (and equivalent C call) to Python objects so that arbitrary objects can be used to slice Python sequences instead of only integers being allowed as is currently the case. Both of these projects are important to the long term success of Numeric computing on Python and would have positive impact on the entire Python community. It is important that somebody takes these on as soon as possible. Thanks, -Travis

1 0

Re: Numeric 3 status
by Travis Oliphant May 19, 2005

May 19, 2005

Eric Jonas wrote: >>I forgot to let you know in my previous email, that I would be very, >>very pleased to receive help on scipy.base. There is a great deal of >>opportunity for people to get involved and assist with the formation of >>a solid scipy.base. I listed a few areas in my previous email, but I'm >>sure I forgot some things. >> >> > >Well, I have an undergraduate working with me with some decent C and >python experience and an interest in numerical computing; we've >downloaded the latest from the SF CVS Numeric3 module and are going to >start looking over things; are there any mailing lists or other >recommended sources of information? As the person in charge of all of >this, is there some area you'd prefer for us to get started on ? We'd >love to help you get this all working this summer... > > Fantastic, Spring term started, and my time for Numeric3 dried up considerably. Fortunately, there is not that much left to do algorithmically but what is left is somewhat difficult. Three things remain for the ufuncs: 1) altered coercion rules to treat scalars differently --- should not be difficult to code (in fact mostly done already SEE scipy.alter_numeric) 2) change the reduce (accumulate), and reduceat functions to handle misaligned and byteswapped data using array iterators and buffers when necessary (i.e. adapt what has been done for general ufuncs to these methods). This is the hard part. I pretty much know how to do it, but it takes a big chunk of time and thought process on my part and I have not been able to get to it for the past month. At the same time, I would like to alter these ufunc methods so that you can specify the argument type they "reduce into" i.e. you should be able to specify that a reduce on a Int8 array returns an output in an Int32 array. 3) add the error handling functionality of numarray. Ufuncs that cause errors will flip the IEEE hardware flag. This needs to be checked if that is the specified error handling mode. This shouldn't take too long. So, #2 is the hard part and is what has me stopped (I know it will take me several hours to days to code it correctly --- and I've not been able to set aside that time). After these three things are accomplished, then what remains is on the critical path is: Updating the scipy numerix module to use scipy.base by default, making sure that scipy.base can ship by itself and have the same basic modules that Numeric provides and a clean path to upgrading to full ATLAS-based linear algebra and/or improved FFT performance. Realistically, this all may not be finished until the scipy conference in September. I'd like it to be done earlier than that of course. The reality is that there are very few actually willing to work on the code base and a great many that will actually want to use it. Those with the C-skill necessary to help (or willing and able to learn some C) are apparently few in number. Any help you provide will be appreciated. You are welcome to tackle anything you think would be useful. -Travis

1 0

Segmenation fault in flapack.zgesdd
by Nils Wagner May 18, 2005

May 18, 2005

Hi all, The enclosed test program stops with a segmentation fault. (gdb) run test_zgesdd.py Starting program: /usr/local/bin/python test_zgesdd.py [Thread debugging using libthread_db enabled] [New Thread 1076102528 (LWP 11378)] numerix Numeric 24.0b2 Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 1076102528 (LWP 11378)] 0x4018d208 in _int_free () from /lib/tls/libc.so.6 (gdb) bt #0 0x4018d208 in _int_free () from /lib/tls/libc.so.6 #1 0x4018d5fb in free () from /lib/tls/libc.so.6 #2 0x4030e17b in array_dealloc (self=Variable "self" is not available. ) at Src/arrayobject.c:630 #3 0x407e3b3a in f2py_rout_flapack_zgesdd (capi_self=0x40294638, capi_args=0x403fd1ac, capi_keywds=0x0, f2py_func=0x408a71f0 <zgesdd_>) at build/src/build/src/scipy/linalg/flapackmodule.c:5753 #4 0x407ee172 in fortran_call (fp=Variable "fp" is not available. ) at build/src/fortranobject.c:277 #5 0x0805928e in PyObject_Call (func=0x40294638, arg=0x403fd1ac, kw=0x0) at Objects/abstract.c:1746 #6 0x080c408d in PyEval_EvalFrame (f=0x8196d64) at Python/ceval.c:3755 #7 0x080c7a54 in PyEval_EvalCodeEx (co=0x4027bf20, globals=0x40259824, locals=0x40259824, args=0x0, argcount=0, kws=0x0, kwcount=0, defs=0x0, defcount=0, closure=0x0) at Python/ceval.c:2730 #8 0x080c7c85 in PyEval_EvalCode (co=0x4027bf20, globals=0x40259824, locals=0x40259824) at Python/ceval.c:484 #9 0x080f63b8 in PyRun_SimpleFileExFlags (fp=0x815e008, filename=0xbfffec0f "test_zgesdd.py", closeit=1, flags=0xbfffe904) at Python/pythonrun.c:1264 #10 0x08055857 in Py_Main (argc=1, argv=0xbfffe9c4) at Modules/main.c:484 #11 0x08054f07 in main (argc=2, argv=0xbfffe9c4) at Modules/python.c:23 (gdb) Any pointer would be appreciated. Nils

3 4

linalg.flapack strange argument in *gesdd
by Nils Wagner May 18, 2005

May 18, 2005

Hi all, A help (linalg.flpack) yields This module 'flapack' is auto-generated with f2py (version:2.46.243_1985) u,s,vt,info = sgesdd(a,compute_uv=1,lwork=(compute_uv?4*minmn*minmn+MAX(m,n)+9*minmn:MAX(14*minmn+4,10*minmn+2+25*(25+8))+MAX(m,n)),overwrite_a=0) u,s,vt,info = dgesdd(a,compute_uv=1,lwork=(compute_uv?4*minmn*minmn+MAX(m,n)+9*minmn:MAX(14*minmn+4,10*minmn+2+25*(25+8))+MAX(m,n)),overwrite_a=0) u,s,vt,info = cgesdd(a,compute_uv=1,lwork=(compute_uv?2*minmn*minmn+MAX(m,n)+2*minmn:2*minmn+MAX(m,n)),overwrite_a=0) u,s,vt,info = zgesdd(a,compute_uv=1,lwork=(compute_uv?2*minmn*minmn+MAX(m,n)+2*minmn:2*minmn+MAX(m,n)),overwrite_a=0) What is the meaning of compute_uv?4*minmn*minmn ? Any idea ? Nils

3 2

QL factorization
by Nils Wagner May 18, 2005

May 18, 2005

Hi all, How can I compute a QL factorization of a m \times n matrix in scipy ? In LAPACK we have http://www.netlib.org/lapack/double/dgeqlf.f Any pointer would be appreciated. Thanks in advance. Nils Reference: Ghavimi and Laub Numerical methods for nearly singular constrained matrix Sylvester equations. SIAM J. Matrix Anal. Appl. 17/1 (1996) pp. 212-221

1 0

AttributeError: GnuFCompiler instance has no attribute 'compiler_so'
by Nils Wagner May 17, 2005

May 17, 2005

Hi all, I tried to install scipy from scratch. python setup.py build failed ... compiling Fortran sources Traceback (most recent call last): File "setup.py", line 124, in ? setup_package(ignore_packages) File "setup.py", line 112, in setup_package url = "http://www.scipy.org", File "/var/tmp/cvs/scipy/scipy_core/scipy_distutils/core.py", line 73, in setup return old_setup(**new_attr) File "/usr/local/lib/python2.4/distutils/core.py", line 149, in setup dist.run_commands() File "/usr/local/lib/python2.4/distutils/dist.py", line 946, in run_commands self.run_command(cmd) File "/usr/local/lib/python2.4/distutils/dist.py", line 966, in run_command cmd_obj.run() File "/usr/local/lib/python2.4/distutils/command/build.py", line 112, in run self.run_command(cmd_name) File "/usr/local/lib/python2.4/distutils/cmd.py", line 333, in run_command self.distribution.run_command(command) File "/usr/local/lib/python2.4/distutils/dist.py", line 966, in run_command cmd_obj.run() File "/var/tmp/cvs/scipy/scipy_core/scipy_distutils/command/build_clib.py", line 115, in run self.build_libraries(self.libraries) File "/var/tmp/cvs/scipy/scipy_core/scipy_distutils/command/build_clib.py", line 218, in build_libraries extra_postargs=[]) File "/usr/local/lib/python2.4/site-packages/scipy/distutils/ccompiler.py", line 81, in CCompiler_compile ccomp = self.compiler_so AttributeError: GnuFCompiler instance has no attribute 'compiler_so' Help is needed. Thanks in advance Nils Python 2.4 (#2, May 12 2005, 14:45:33) [GCC 3.3.3 (SuSE Linux)] on linux2 Type "help", "copyright", "credits" or "license" for more information. f2py -v numerix Numeric 24.0b2 2.46.243_1985 g77 -v Reading specs from /usr/lib/gcc-lib/i586-suse-linux/3.3.3/specs Configured with: ../configure --enable-threads=posix --prefix=/usr --with-local-prefix=/usr/local --infodir=/usr/share/info --mandir=/usr/share/man --enable-languages=c,c++,f77,objc,java,ada --disable-checking --libdir=/usr/lib --enable-libgcj --with-gxx-include-dir=/usr/include/g++ --with-slibdir=/lib --with-system-zlib --enable-shared --enable-__cxa_atexit i586-suse-linux Thread model: posix gcc version 3.3.3 (SuSE Linux)

2 2

Fuzzy logic library for SciPy
by Prasan Samtani May 16, 2005

May 16, 2005

Greetings scipy-devers, I am currently beginning work on a Fuzzy Logic toolkit in Python (modeled after the MatLab fuzzy logic toolbox http://www.mathworks.com/products/fuzzylogic/). Before I get ahead of myself, I was wondering if someone has already been working on something like this, I want to make sure I'm not reinventing the wheel. Thanks, Prasan

1 1