Mailman 3 April 2004 - SciPy-Dev

SPHEREPACK module
by Jeff Whitaker April 17, 2004

April 17, 2004

Hi: I've written a python wrapper for NCAR's SPHEREPACK library for spherical harmonic computations, using f2py. The module is available at ftp://ftp.cdc.noaa.gov/Public/jsw/spharm.tgz, with documentation online at ftp://ftp.cdc.noaa.gov/Public/jsw/spharm/doc/html/index.html. I'd be happy if it could be included in SciPy, but I'm afraid the SPHEREPACK license might prevent that. The SPHEREPACK source code is freely available, but the license appears to forbid redistributing it (http://www.scd.ucar.edu/css/software/spherepack/sp.form.html). f2py never ceases to amaze me - thanks Pearu! -Jeff -- Jeffrey S. Whitaker Phone : (303)497-6313 NOAA/OAR/CDC R/CDC1 FAX : (303)497-6449 325 Broadway Web : http://www.cdc.noaa.gov/~jsw Boulder, CO, USA 80305-3328 Office: Skaggs Research Cntr 1D-124

1 0

Python interface to COBYLA
by Jean-Sebastien Roy April 15, 2004

April 15, 2004

Hi ! Following my previous mail, I did a preliminary Python interface to M.J.D. Powell COBYLA optimization package. I translated the Fortran package to C via f2c, did a few adjustments, and added a Python interface so it could be easily integrated into SciPy. As stated in a previous mail, M.J.D. Powell agreed for the inclusion of COBYLA in SciPy. (Many thanks to him !) COBYLA stands for Constrained Optimization BY Linear Approximation. Two things make COBYLA an interessting algorithm to have in SciPy: - It's derivative free (like Nelder-Mead) ; - It can take non-linear constraints. It has some drawbacks: - It won't probably work if there are too many variables (say > 10) ; - The constraint are not exactly enforced during the minimization ; - It may be quite slow, most notably if there are no constraints. In the last case, a higher performance unconstrained derivative free method like Powell's UOBYQA or NEWUOA should probably be used. (Conn-Scheinberg-Toint DFO is anoter option) I've attached the preliminary Python interface. Suggestions are welcome! Regards, js

3 6

Re: [SciPy-dev] Python interface to COBYLA
by Tom Loredo April 15, 2004

April 15, 2004

> So, unless there is an important reason to convert to C (dynamic memory > llocation for example), I would think it is better to keep Fortran code > in Fortran when possible. One reason is that Mac OS 9 users don't have a free FORTRAN compiler to use. This has thwarted my use of scipy in the past. I've pretty much switched to OS X now. There one can get g77 via the Fink project. It's too bad it's not in the Apple Developer Tools (not sure about the latest version...) since it places one more obstacle in the path of Mac users wanting to use scipy. -Tom

1 0

import scipy -> SIGSEGV?
by Alok Singhal April 13, 2004

April 13, 2004

Hi all, OK, I have spent two days trying to figure out what the problem migh be, but I give up. I installed scipy on a Redhat 9 system (as a user in my home directory), and when I do: $ python >>> import scipy It says: Segmentation fault The core dump shows SIGSEGV is received in fastumath_unsigned.inc, line 2858: add_functions[11] = PyUFunc_OO_O; The relevant backtrace is: #0 InitOperators (dictionary=0x81b75a4) at fastumath_unsigned.inc:2858 #1 0x40078f9f in initfastumath () at /users/asinghal/SciPy-0.2.0_alpha_200.4161/scipy_core/scipy_base/fastumathmodule.c:92 #2 0x080921ef in _PyImport_LoadDynamicModule () #3 0x08090003 in PyImport_ExecCodeModuleEx () (gdb) p add_functions[10] $2 = 0x4006f180 <CDOUBLE_add> (gdb) p add_functions[11] $3 = 0 (gdb) p &add_functions[11] $4 = (PyUFuncGenericFunction *) 0x4007bbcc Line 2722 of scipy_core/scipy_base/fastumath_unsigned.inc defines add_functions to be a 12 element array, so an assignment to add_functions[11] should work. I used the SciPy-0.2.0_alpha_200.4161_src.zip code to compile scipy. I am using the following: - Python 2.2.2 (RPM python-2.2.2-26) - Numeric 23.1 - ATLAS 3.6.0 (+LAPACK) - f2py 2.39.235_1693 - fftw 3.0.1 (though it failed to detect fftw during installation of scipy) - gcc (GCC) 3.2.2 20030222 (Red Hat Linux 3.2.2-5) Importing Numeric works fine. I am not sure where the problem is, but if you need any other information, I will be glad to provide it. Alok -- Alok Singhal (as8ca(a)virginia.edu) * * Graduate Student, dept. of Astronomy * * * University of Virginia http://www.astro.virginia.edu/~as8ca/ * *

2 1

Nonlinear constrained optimizer in SciPy
by Jean-Sebastien Roy April 12, 2004

April 12, 2004

Following an earlier exchange with eric jones, I would like to suggest the addition of a non linear constrained optimizer to SciPy (a functionnality currently lacking). In 2001, a colleague and I did a review on non-linear bound constrained optimizer that only required the gradient of the function to be optimized. We did our review mosty based upon softwares listed in H. Mittlemann optimization guide (http://plato.la.asu.edu/guide.html), the non linear programming faq (http://www-unix.mcs.anl.gov/otc/Guide/faq/) and the NEOS guide (http://www-fp.mcs.anl.gov/otc/Guide/), plus a few other soucres (HARWELL notably). We tested about 12 different optimizers for which the source code was available and the result, while foreseeable, was not very interesting : performance is largely dependent on the problem, and tuning of the solvers parameters can result in huge performance increases. Nevertheless, in this restricted class of optimizers, a few emerged as quite good on a variety of problems. Some of them would probably be good candidates for inclusion in SciPy. (Note: Very few codes come with a license explicitly allowing free redistribution and inclusion in commercial software) L-BFGS-B: The Fortran source can be downloaded here: http://www.ece.northwestern.edu/~nocedal/lbfgsb.html We wrote to Nocedal who did not to oppose inclusion in our software, so maybe we could ask him for inclusion in SciPy ? It was the simplest to use, iterations are fast, and it was quite robust. Probably the first code I would try on any problem. M2QN1: The Fortran source can be extracted from the scilab distribution. See also: http://www-rocq.inria.fr/estime/modulopt/optimization-routines/m2qn1.html An LBGFS code like the previous one, reasonnably simple to use, very fast, very efficient. The use in commercial software if forbiden by scilab's licence, but we may still ask the author, Claude Lemaréchal, who is a very nice person. TNBC: http://iris.gmu.edu/~snash/nash/software/software.html A bound constrained truncated newton code. Stephen Nash did not oppose use in our code, and since this code provided the best performance on our problem (which may not be the case on other problem), I did a C version of it (with some modifications) and recently added a Python interface. It's distributed with a BSD license, so it could be readily integrated in SciPy (but I'm obviously biased). You can download it here (look for TNC): http://www.jeannot.org/~js/code/index.en.html A few more general codes: DONLP2: http://plato.la.asu.edu/donlp2.html SQP code with non linear constraints (including equality constraints). While it was quite difficult to use in our problem, it works well, and is very general. The licence oppose commercial use, but we could ask the author, Peter Spellucci about inclusion in SciPy. TRON: http://www-unix.mcs.anl.gov/~more/tron/ Trust region newton code. Fast iterations. Sparse Hessian estimation using finite differences, so it may be more difficult to use (since the sparsity pattern should be computed). Again, Jorge More must be asked about inclusion. Other interesting codes include: IPOPT: http://www-124.ibm.com/developerworks/opensource/coin/Ipopt/ An interior point code, very general (non linear equality constraints, bounds). We did not review it (its quite recent). It comes with a free license, so integration in SciPy should be possible. (Some options of IPOPT requires part of the HSL library, which cannot be used in commercial software). DFO: http://www-124.ibm.com/developerworks/opensource/coin/faqs.html#DFO A derivative free optimisation code, which, like IPOPT, comes with a free license. But it requires a non-linear gradient based optimizer and some developpement. COBYLA: http://plato.la.asu.edu/topics/problems/nlores.html Another alternative for derivative free optimisation, which seems free. There are probably other codes, better alternatives, which should be considered for inclusion in SciPy. Any suggestions ? Regards, js

4 7

Resolving win 32 problems
by Ted Bach April 8, 2004

April 8, 2004

Dear Scipy Developers, I am considering using scipy as a foundation and helper package for my own SIMP/STEP (http://pm.bu.edu/step) software for cellular automata and lattice gas experiments. The scipy environment would be helpful in providing rendering and viewing capabilities, allowing external compilation of fast routines via weave, as well as providing auxilary libraries for plotting statistics gathered from long simulations. I have been quite impressed with scipy on Linux, however, an important aspect of my choice is Win32 compatability. Unfortunately, I have not been able to get any of the Win32 binaries to work at all. For example, simply importing scipy causes a crash! (On Windows XP with python2.3 and SciPy-0.2.1_260.4162.win32-py2.3.exe and Scipy_core-0.2.2_alpha_108.1756.win32-py2.3.exe). I have seen several reports that the Windows release has not been working (on the Bug Tracker) and have begun to wonder how far the project has drifted from Windows compatability and whether the problems are serious. Are there plans to fix these problems in the near future? Since I am quite keen to use scipy and potentially integrate my software with it down the road, I would be happy to spend some time trying to address these issues myself if someone can point me to the current suspected problems and the strategy (if it exists) for overcoming them. Cheers, Ted Ted Bach tbach(a)bu.edu |home: Boston University 617/353-0294 |617/776-2926 ECE Dept. fax -6640 |223 Somerville Ave Apt 2 8 St Mary's St. |Somerville, MA 02143 Boston, MA 02215 |

3 3