Mailman 3 May 2005 - SciPy-Dev

IDL to Python converter available
by Christopher Stawarz 30 May '05

30 May '05

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 26 May '05

26 May '05

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 20 May '05

20 May '05

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 19 May '05

19 May '05

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 19 May '05

19 May '05

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 18 May '05

18 May '05

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 18 May '05

18 May '05

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 18 May '05

18 May '05

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 17 May '05

17 May '05

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 16 May '05

16 May '05

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

On reverse engineering
by Fernando Perez 12 May '05

12 May '05

Hi all, there have been recent discussions on this list on this topic. For those interested, this seems to be a good discussion with a reasonable amount of legal background: http://lwn.net/Articles/134642/ I don't want to turn this into a debate, just to provide useful background info in case the issue comes up again (which unfortunately we all do face one way or another when free software begins to come close to the realm of proprietary stuff, be it IDL, Matlab, or anything else). Cheers, f

1 0

Problem with building scipy
by Nils Wagner 11 May '05

11 May '05

Hi all, Building scipy from latest cvs failed building 'mach' library 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' Nils

2 2

Compilation problems (and solutions...) on HP-UX B.11.00
by Nicolas Pernetty 06 May '05

06 May '05

Hello, I've just almost managed to get scipy 0.3.2 compiled, up and running on HP-UX B.11.00 and here are some issues I had to deal with : 1) There should be some way to choose the fortran 77 compilers instead of manually editing the .py files, but maybe there is an environment flag I'm not aware of ? 2) ./Lib/xplt/src/play/unix/fpuset.c had to be modified in order to have it compiled correctly on HP-UX : **************************************************************** #elif defined(FPU_HPUX) /* man pages: fpsetmask * library: -lm */ /* HPUX turns off FP_X_* without this (_INCLUDE_HPUX_SOURCE) */ #ifndef _HPUX_SOURCE #define _HPUX_SOURCE 1 #endif #include <math.h> void u_fpu_setup(void) { fpsetmask(FP_X_INV | FP_X_DZ | FP_X_OFL); /* 0x1c */ fpsetfastmode(1); /* fast underflows */ } **************************************************************** has to be replaced by **************************************************************** #elif defined(FPU_HPUX) /* man pages: fpsetmask * library: -lm */ /* HPUX turns off FP_X_* without this (_INCLUDE_HPUX_SOURCE) */ #ifndef _HPUX_SOURCE #define _HPUX_SOURCE 1 #endif #include <fenv.h> void u_fpu_setup(int when) { if (when <= 0) { fesettrapenable(FE_INVALID | FE_DIVBYZERO | FE_OVERFLOW); } } **************************************************************** 3) In addtion to 2), you have to add math library '-lm' in order to compile fpuset.c. I solved it by editing ./Lib/xplt/config_pygist.py and replace the line 297: elif self.try_link("#define FPU_HPUX\n"+testcode, by elif self.try_link("#define FPU_HPUX\n"+testcode,libraries=[self.mathlib], 4) I had a "Bus Error (core dumped)" when calling the gamma.c function in ./Lib/special/cephes/gamma.c during the test scipy.test(level=1) It seems that the global variable P and Q are incorrectly defined, so I decided to use decimal configuration and add at the top of the file : #undef MIEEE #define UNK It seems to take care of the problem and I had no more errors when calling scipy.test(level=1) 5) When calling : python import scipy scipy.test(level=1, verbosity=2) The computer gets locked, it seems to get stuck in an infinite loop. I have to manually kill the python process But If I type : python -v import scipy scipy.test(level=1, verbosity=2) thus having displayed all the imported modules, everything goes fine ! All tests gets tested and are ok... Don't know if it's a python problem or a scipy problem though... 6) Can you add to the INSTALL.txt file that in order to get scipy find the fftw and ATLAS libraries you have to use an environment var locating both the libraries AND the headers ? I spent more than an hour before understanding that I have to use export ATLAS=/usr/local/lib/atlas:/usr/local/include/atlas instead of just export ATLAS=/usr/local/lib/atlas Hope that all this will help others and this great piece of software ! Regards,

2 2

scipy.test outputs
by Stephen Walton 05 May '05

05 May '05

Just for everyone's FYI, I uploaded the results of scipy.test() from version 0.3.3_303.4602 to the scipy.org bug tracker. A rather large number of tests seem to be failing; I'm getting 107 failures on a dual Athlon running Fedora Core 1 and 75 on a P4 running Fedora Core 3, both with Numeric 23.8 and ATLAS 3.6.0. Is anyone else seeing similar numbers?

1 1

implementing IDL, Matlab, etc. functionality
by Joe Harrington 05 May '05

05 May '05

Two of the big barriers to people converting from commercial environments to SciPy are 1) their dependence on specific packages in those languages (e.g., the fuzzy logic package in Matlab that was recently mentioned, or the IDL Wavelet Toolkit), and 2) their dependence on their own code, developed over the course of their career. There are legal issues we need to be aware of in coming up with solutions. There are two problems: first, to use IDL (and, I assume, Matlab), you have to agree to a license that says you will not reverse engineer the product. The packages include a lot of routines in source form. Most users who are likely to write compatible packages in SciPy have looked at these routines. They thus have "tainted brains": the commercial entity can claim that they have seen proprietary information, and that they had to use this information to produce the Python package. Second, Cornell's legal staff has informed me that there are two court precedents that state that if you have *ever* used a product, and you try to make something that works the same way, it's reverse engineering. I know that sounds ludicrous to everyone, it does to me, but you may have to fight at the Federal Appeals level or above to be sure. Again, since users of IDL and Matlab have agreed to licenses that prohibit reverse engineering, this would mean that any code produced by such people would be tainted and we could be sued. "We" means us as individuals, our institutions (who employ us, pay us, and might be construed as the licencees of IDL and Matlab), Enthought for distributing it, etc. Regardless of how crazy this interpretation might sound, I doubt that we as a community have the financial resources to mount an appeal. There is also no shortage of crazy legal interpretations that stick in current computer law, so there is no guarrantee that we'd win. One of the original plaintiffs was Sony, which would surely weigh in with amicus briefs and perhaps financial help to the plaintiff, since their IP would be at stake if their precedent were turned over on our appeal. I think there is a technical way out, however. I have only agreed to an IDL license. Nothing says I can't implement something that works like Matlab. Reverse engineering is legal, at least in the great state of New York, unless you sign that right away. So, it makes some sense to set up some trades: I can write a Matlab -> Python converter if you'll do it for IDL. All that's needed is for each side to provide examples of code in the proprietary language that they have written themselves, along with descriptions of what it does and sample inputs and outputs. That plus commercial books on the languages should provide all the information we need. For specific packages, it makes more sense for people to do them from scratch or by wrapping existing open-source code. For one thing, the efforts of the commercial packages are usually old and almost always procedural. Much is to be gained implementing as a good OO design based on the method descriptions in the literature and the particular strengths of scipy.base. Then, someone else who has not signed a license can do workalike interfaces for the commercial packages. The benefit here is that IDL and Matlab are pretty backward languages, whereas Python is quite modern. Matlab users may benefit from encountering a Matlab-compatible fuzzy logic interface, but IDL users certainly don't. It would be much better for them to learn the OO interface. The reverse is of course true for, say, IDL wavelets. So, before anyone (else) goes diving into implementing something from IDL, Matlab, etc., please give consideration to these issues. --jh--

6 9

linalg.solve and singular systems
by Nils Wagner 04 May '05

04 May '05

Hi all, I was surprised about the behaviour of linalg.solve in case of singular/nearly singular coefficient matrices. The user should get at least a warning. The singular values clearly show that the matrix is ill-conditioned. Any comment or suggestion would be appreciated. Thanks in advance Nils

1 0

scipy.special for numarray
by Todd Miller 02 May '05

02 May '05

scipy.special now passes all its self tests with numarray using the tarball of modifications found here: http://www.stsci.edu/resources/software_hardware/numarray/scipy_special_num… To try this out, the following works on Linux: 0. Get & unpack the tarball % wget http://www.stsci.edu/resources/software_hardware/numarray/scipy_special_num… % tar zxvf scipy_special_numarray.tar.gz scipy_special_numarray/ scipy_special_numarray/updates.txt scipy_special_numarray/diffs.txt scipy_special_numarray/na_cephes.py scipy_special_numarray/cephes.py scipy_special_numarray/gen_na_cephes.py scipy_special_numarray/_na_cephesmodule.c scipy_special_numarray/nc_cephesmodule.c 1. Checkout scipy from CVS on scipy.org. 2. Apply the diffs % cd scipy % patch -p0 <../scipy_special_numarray/diffs.txt 3. Save the "added files" into scipy/Lib/special. % cd .. % cp scipy_special_numarray/{*.py,*.c} scipy/Lib/special 4. Build scipy (it's important to have both numarray & Numeric already installed): % cd scipy % python setup.py build_ext --backends=numeric,numarray install --force 5. Numeric is the default array package; make sure still works: % python >>> import scipy >>> scipy.test() ... <output clipped> Ran 676 tests in 3.115s OK 6. Running using numarray requires setting the environment variable NUMERIX to numarray. It should be noted that not all of scipy has been ported to numarray yet: only scipy_core (except for weave) and scipy.special have been ported so only scipy.special is tested here. % setenv NUMERIX numarray % python >>> import scipy.special as spec >>> spec.test() ... <less output clipped> Ran 342 tests in 2.279s OK A top level overview of the changes is in updates.txt. Barring any objections I'll commit these changes one week from today. Comments are welcome. Regards, Todd

1 0

Re: [SciPy-dev] implementing IDL, Matlab, etc. functionality
by Venkat Raghavan V.C. 02 May '05

02 May '05

> There are legal issues we need to be aware of in coming up > with solutions. I was scared that I was missing something. > I think there is a technical way out, however. I have only agreed to > an IDL license. Nothing says I can't implement something that works > like Matlab. Reverse engineering is legal, at least in the great > state of New York, unless you sign that right away. So, it makes some > sense to set up some trades: I can write a Matlab -> Python converter > if you'll do it for IDL. All that's needed is for each side to > provide examples of code in the proprietary language that they have > written themselves, along with descriptions of what it does and sample > inputs and outputs. That plus commercial books on the languages > should provide all the information we need. Sad, if we resort to this! > For specific packages, it makes more sense for people to do them from > scratch or by wrapping existing open-source code. There have been three packages in which I have used the controls "module", 1. scilab, which is open-source, but not free . (Scilab license forbids you to: use a composite or derived version of Scilab for commercial uses without asking INRIA authorization. http://scilabsoft.inria.fr/legal/index_legal.php?page=faq.html ) 2. GNU-Octave, which is free ( GPL) 3. Matlab, which is closed source. I guess I can look to Octave for pointers. But at this > So, before anyone (else) goes diving into implementing something from > IDL, Matlab, etc., please give consideration to these issues.

1 1

in-line graphics
by Salsifis 02 May '05

02 May '05

Dear Scipy developpers, Thanks for the work on scipy and the related effort to bring scientific computing solutions to open-source. I'm in the effort to translate my MATLAB scripts into scipy and the learning curve is steep. I particularly appreciate iPython (so this is perhaps OT on the scipy ML) as a solution to have a researcher-friendly interface. A killer (and that will convince many people around me still sticking to MATLAB) would be to enable inline graphics, as was the case in mathematica. This would be : - a very good way to interact with your code (I love to use hist() to know wehere my variables live), - an easy way to create simple reports of results or to include in paper to allow replication of results (export session to pdf) - an excellent way to produce tutorials for schools (as standalone .py files) Unfortunately, may coding abilities don't even permit me to gauge if this feature is a snap to code or if it involves calling for mysterious extra-human forces... Also, I wish to stress that it's not a call for a "visual scipy" with a lot of avoidable features (no offense to Matlab :) ) but just a simple way to include in the same window a graphic ouput to a command-line request... Cheerts, Laurent exemple (inspired by travis' tutorial) : >> from pylab import * >> plot([1,2,3,4]) >> plot([1,2,3,4], [1,4,9,16], 'ro') >> axis([0, 6, 0, 20]) >> savefig('secondfig.png')

2 1

Re: in-line graphics
by Brendan Simons 02 May '05

02 May '05

I would immediately pay for such an app. I've fought with MathCAD/Mathematica/Matlab way too often already. Development wise, I can't see how this would be too difficult. You would have to merge iPython with matplotlib and a wysiwyg editor. I think the biggest hurdle would be choosing a gui kit, since no one kit makes everybody happy. -Brendan On 2-May-05, at 6:11 AM, scipy-dev-request(a)scipy.net wrote: >>A killer >>(and that will convince many people around me still sticking to >>MATLAB) >>would be to enable inline graphics, as was the case in mathematica. ______________________________________________________________________ Post your free ad now! http://personals.yahoo.ca

2 1

interesting floating point discussion
by Alan G Isaac 02 May '05

02 May '05

It's Java focused, but more generally applicable. http://www.cs.berkeley.edu/~wkahan/JAVAhurt.pdf I have no idea how Python has responded to these issues. A pointer to an accessible discussion would be welcome. Thanks, Alan Isaac

2 2