Mailman 3 August 2000 - NumPy-Discussion

ANNOUNCE (Numeric): Some RPMS and a GIST interface I use regularly.
by Travis Oliphant 11 Sep '00

11 Sep '00

Just letting interested people know that I've made RPM's of the Python interface to all of Lapack originally written by Doug Heisterkamp and modified by Konrad Hinsen (Konrad, you may have already made these --- please let me know if you have). (Under Numerical Python RPMS at) http://oliphant.netpedia.net Also, I've released a module I use regularly for interactive plotting with Gist. It makes it much more "MATLAB" like: from Mplot import * mplot(x,y,'r-',x2,y2,'b:') legend(['Line1',Line2']) # will prompt you for a place to put it. title("Title") xlabel("some label") ylabel("other label") You can also do subplots with the module using gist.plsys to change between subplots. I use it everyday and thought others might be interested in it. It's not well documented at this point, though. Needed files: http://oliphant.netpedia.net/packages/Mplot.py http://oliphant.netpedia.net/packages/write_style.py The latter file allows one to construct a gist style file from a Python nested dictionary which is needed for changing the color and style of the axis system. -Travis

3 3

ANNOUNCE: New algorithms added to optimize.py
by Travis Oliphant 31 Aug '00

31 Aug '00

This is a heads up to those interested in Python-implemented optimization algorithms. I've updated my optimize.py module to version 0.3 by including two new unconstrained optimization algorithms to minimize a function of many variables -- one which implements a quasi-Newton algorithm (BFGS) and another which implements a practical Newton's algorithm using conjugate gradients to invert the Hessian (approximated if not provided). The license is very liberal it's available at http://oliphant.netpedia.net/packages/optimize.py Here are the docstrings: >>> print optimize.fminBFGS.__doc__ xopt = fminBFGS(f, fprime, x0, args=(), avegtol=1e-5, maxiter=None, fulloutput=0, printmessg=1) Optimize the function, f, whose gradient is given by fprime using the quasi-Newton method of Broyden, Fletcher, Goldfarb, and Shanno (BFGS) See Wright, and Nocedal 'Numerical Optimization', 1999, pg. 198. >>> print optimize.fminNCG.__doc__ xopt = fminNCG(f, fprime, x0, fhess_p=None, args=(), avextol=1e-5, maxiter=None, fulloutput=0, printmessg=1) Optimize the function, f, whose gradient is given by fprime using the Newton-CG method. fhess_p must compute the hessian times an arbitrary vector. If it is not given, finite-differences on fprime are used to compute it. See Wright, and Nocedal 'Numerical Optimization', 1999, pg. 140.

1 0

Re: Numpy-discussion digest, Vol 1 #90 - 3 msgs
by Rob Managan 29 Aug '00

29 Aug '00

When trying to build the 16.0 release on the Mac I found that I had to modify fftpackmodule.c so that line 3 was #include "arrayobject.h" instead of #include "Numeric/arrayobject.h" What was the reason for the Numeric in the first place? It seems that arrayobject.h is now in the Include directory anyway. -- *-*-*-*-*-*-*-*-*-*-**-*-*-*-*-*-*-*-*-*-*- Rob Managan <mailto://managan@llnl.gov> LLNL ph: 925-423-0903 P.O. Box 808, L-095 FAX: 925-422-3389 Livermore, CA 94551-0808

1 0

Re: [Numpy-discussion] lapack_lite
by Jack Jansen 28 Aug '00

28 Aug '00

> That would be me, and it is fixed now. I had done a cvs add, and created a > directory and put stuff in it, but I think I moved it to a different name > temporarily for a test and didn't put it back, so when I did the commit it > was missed. Thanks! > Jack, I will add you to the developer list so you can check in your macisms. Okay, great. I'll probably stick with Mac subdirectories on the toplevel and lapack-lite level which will contain the mac project files (and possibly any config header files or so, but I think Numeric didn't need them last time around). I've also started ansifying the numeric stuff for Python 2.0 (mainly taking out the Py_PROTO and Py_FPROTO macros, which have disappearded) but I won't check that in right now (I don't know whether you want to do a Numeric-for-Python-1.6 distribution, and I don't remember whether 1.6 was fully ansified), but let me know when/if you want this checked in. -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen(a)oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.oratrix.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm

1 0

lapack_lite
by Jack Jansen 28 Aug '00

28 Aug '00

The lapack_lite directory is empty in the sourceforge repository. And according to the build docs it shouldn't be. Could whoever has the contents please check them in, or (if they should come from a different place) please tell me where to find them? Right now I can't build from the repository, and I'd like to get Numeric working with the latest release for MacPython 2.0. -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen(a)oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.oratrix.nl/~jack | ++++ see http://www.xs4all.nl/~tank/ ++++

2 1

History and Why NumPy2 (long)
by Travis Oliphant 27 Aug '00

27 Aug '00

Greetings to all interested in Numerical Python, My purpose in writing this somewhat long post is to inform interested parties as to where NumPy is going and how far it has gone. I'm doing this in order to coordinate interest and try to summarize some of the recent conversations I've had with other interested people. There are a significant handful of people who are very interested in where Numerical Python is going. All of these people are very bright and have distinct desires for the future of Numerical Python which come from quite diverse experience. This intelligence and diversity brings tremendous strength (both current and potential) to the community and has made Numerical Python an extremely useful tool. Of course, these benefits do not come cheaply: there is quite a bit of disagreement about how things should be done --- mostly due to the fact that people use Numerical Python for different things. Fortunately, this disagreement is not insurmountable provided people are willing to compromise a little syntatic sugar here and there. Numerical Python users have been enjoying the flexibility and power of the underlying programming language for several years. The price we must pay for using a language that is not wholly dedicated to Numerical pursuits, is that we must cooperate with other users of the core language who have interests entirely different than our own. Since Numerical programming is rarely "strictly numerical," what we gain is access to the work they do in improving Python's stock of library tools. When I was introduced to Numerical Python system, some of the results of this compromise were a little annoying to me --- somewhat like the whitespace rule. What I found, however, was that my annoyance gave way to elation as I realized that the non-numeric objects and toolkits where extremely beneficial to me in my numeric work: regular expressions, serving graphs from a website, writing translators for various files and formats, etc. With that introduction, I'll give a brief history of Numerical Python (please forgive me if I have neglected important contributors). Numerical Python started from the work of Jim Hugunin (which he used as part of his Oral Examination at MIT). He posted an announcement of his proposal in August of 1995 based on the Matrix Object previsouly presented by Jim Fulton. Early discussions of the work can be found at http://www.python.org/pipermail/matrix-sig/ which presents very interested reading since many of the topics peole still talk about were hashed even back then. Konrad Hinsen, Paul Dubois, David Ascher, and Jim Fulton were all early contributors. Jim Fulton's work and connections to Guido Van Rossum enabled many of the early changes (extended slicing, complex numbers, ellipses) to get into Python itself. Guido was also part of the early discussion. Konrad Hinsen contributed a significant amount of code to the current version of Numeric Python as well. Jim Hugunin released version 0.2 in December of 1995 and followed the release early, release often model for several months to get Numerical Python into a working state. It is obvious that he spent many hours writing code (time which NumPy2 contributors have not been able to duplicate). One thing that led to some stall in Numerical Python's development is that Jim Hugunin left the project to concentrate on JPython. Paul Dubois picked up the task of project administrator and has done an admirable job, including securing resources to get the current documentation written. David Ascher wrote the bulk of that important resource. Personally, I started using Numerical Python after scouring the Net for something to replace MATLAB for me which had become burdensome under the weight of large data volumes and inefficient memory handling. I started using Numerical Python in the Spring of 1998 ( a relative late-comer ) but I have used it actively ever since. I started releasing packages at that time to increase the number of toolboxes available to the Numerical Python programmer as I was quite happy with the language itself (after I got over the initial annoyances). I've released many pieces of code since then which I personally use quite regularly. Most of these can be found at http://oliphant.netpedia.net Naturally my contributions have been in areas where I had a personal need, but they have enabled me to understand the Numerical Python source code enough to feel confident in modifying it. With that bit of history let's get into why NumPy2: Guido Van Rossum has expressed willingness to include multidimensional arrays into the Python core. The source of this willingness appears to be a general respect for the community of users who use Python for Numerical programming (although he himself is not one of those users). There is already a useful one-dimensional array object distributed with Python which, however, does not support any operations. Some of it's features where borrowed for the current Numerical Python. Last year, I suggested that the PIL and Numeric Python work more closely together (since an image is conceptually just a 2-D (or 3-D for color) Numeric Python array). /F from pythonware responded by saying that until Numeric Python was a part of Python itself he saw no reason to modify the PIL. I took the bait and after pondering why 4 years had elapsed without Numerical Python getting into Python itself, I contacted Guido and Paul to start the ball rolling. Guido's response was that those familiar with the code said it was too ugly and unwieldy to put into Python. The code is just too hard to modify and understand. Evidently, since there are only a handful of people of the hundreds that use it who submit bug patches, or feature enhancements, this must be true. Those who do understand how it works have a hard time finding time to make needed changes --- the intrinsic cooperation problem with volunteer time that is not funded (or contributed to) by those who make use of the results. Guido was kind enough to provide me with some design documents for an implementation of multidimensional arrays that he had worked out. Thinking I would be in graduate school for longer than I am going to be, I set about trying to clean up Numerical Python with the intent of getting it into the Python core. As part of this effort I conducted a survey of current Numerical Python users to find out their interests. The survey and it's results are available at the sourceforge site for Numerical Python. Basically the results indicate that most people agree on some important features (like arbitrary indexing into arrays), but disagree on some details (copy vs. reference and automatic casting rules being the most memorable). While the results were useful, a simple comment made by one of the survey participants made a significant impression on me: "the C-code is too inflexible and hard to change." This is essentially the problem that Paul Dubois had identified and which was keeping Numerical Python out of the Python core. At the same time I had been doing some work with implementing a sparse matrix package for Python by wrapping some compiled C and Fortran code into a Python class I'd constructed. The results were very encouraging and made me realize that the same technique could be used to make Numerical Python much more flexible and easier to extend while retaining it's significant speed benefits. I decided to make a new implementation of Numerical Python where the underlying objects (the array and ufunc objects) are not extension types but true Python classes. This would allow significant benefits in terms of flexibility and modifiability with a small memory-overhead loss and an indeterminate speed change (it will likely be faster under some usages and slightly slower in others). I also wanted to add more types (unsigned types, boolean, and potentially others). While making this change, I realized that another way out of the "type-class" dichotomy (along with ExtensionClasses) is to not make new types at all. If all types were really ExtensionClasses and all new types had to be as well, this could effectively solve the problem from the Python user perspective as well. An noble effort at making Numerical Python an Extension Class was undertaken by David Ascher last year. His work became the ill-fated Numerical Python 12. I rather liked his work, but there were some very hard to trace bugs in the implementation, and the C-code was still hard to modify. Another problem (that must be dealt with with the new implementation as well) is the significant amount of code that has been written to the old C-API. This finally brings us to the state of Numerical Python. I've been working on this implementation on and off for six months (mostly off), but have worked out many of the design details. Since my time is currently limited for the next 3 months, I wanted to let others know of the status to encourage involvement. We have a window here to get this next version of Numeric into Python 2.1, but the window will probably close sometime in January, so there is some urgency. In the next installment, I will outline the design of Numerical Python 2 and some of it's goals. -Travis Oliphant

2 3

Announce: Pyfort 6.0
by Paul F. Dubois 26 Aug '00

26 Aug '00

There is a new Pyfort on SourceForge. Type pyfort with no arguments to get usage info. Incompatible change required: Remove the module/end module pair of statements from your .pyf Documentation: in pdf and HTML at http://pyfortran.sourceforge.net. See the project page at http://sourceforge.net/projects/pyfortran for downloading Pyfort-6.0.tar.gz. The new version builds and installs extensions in just one line. For example, if you have created an input file mydiagostic.pfy, using Fortran library libmydiags.a located in directory /myhouse, then pyfort -i -l mydiags -L /myhouse mydiagnostic.pyf makes mydiagnostic.so and installs in Python's site-packages directory (assuming you have write permission there). It is now much easier to figure out how to add a "compiler id" for a new platform. I wouldn't say it is completely easy, but it is "easier". I hope people will post patches to fortran_compiler.py to add their favorites. I have only tested the Linux g77 / pgf77 combinations. pgf90 (Portland Group F90, Linux), g77alpha (g77 on an alpha chip)and solaris (Sun Solaris Fortran) "should" work. Numeric Python, and 0.9 or better Distutils are assumed; see documentation for details.

1 0

Why I wrote the previous posts.
by Travis Oliphant 24 Aug '00

24 Aug '00

For those wondering why I wrote the previous posts (and didn't bother to correct the spelling mistakes :-) ) it is due to a request from Greg Wilson who is bending the ear of other contributors to Numerical software that are not in the Python community. He asked that I quickly hash out some words on Numerical Python and where it is going for him --- so I did and crossposted what I wrote to this list since I thought some might be interested in my position and goals. --Travis

1 0

VSIPL?
by Janko Hauser 21 Aug '00

21 Aug '00

Just by chance I found the link to an ANSI-C library which looks interesting in the light of the reimplementation of NumPy. The link is: http://www.vsipl.org/ I can not decide, if the design decisions made by the authors of this library or this spec are good or not. But they mention a lot of topics coming up on this list from time to time, like different views of the data space, gather/scatter, interfacing to Fortran. Are there people on the list, which do know this library and the possible problems or merits of it? This library was used as an positive design example in a discussion about the GSL. Regarding the redesign, I often get confused, because there are so many libraries, which do all implement there own vector/matrix/tensor definitions, so the question is, if the new NumPy should have more characteristics of an interface, so that the underlying numeric engine could be changed. Would it help in such a case to wrap a library as a first proof of concept? <only-a-light-distraction-from-new-syntactic-sugar>'ly __Janko

2 1