Mailman 3 March 2002 - NumPy-Discussion

[ANN] Pyfort-7.0b2 -- extending Numeric with C routines
by Paul F Dubois 24 Mar '02

24 Mar '02

Pyfort 7.0b2 is now available at sf.net/projects/pyfortran. Nummies who do not use Fortran may be interested in using Pyfort; with Michiel de Hoon's "C" option, it is now extremely easy to wrap a simple kind of C code for processing Numeric's arrays, like this: double ctry(int n, double* x, double* y) { int i; double d; d = 0.0; for (i=0; i < n; ++i) { d += x[i] * y[i]; } return d; } void cout(int n, double* x, double* y) { int i; for (i = 0; i < n; ++i) { y[i] = 1.414159 * x[i]; } } double c2(int n, int m, double x[n][m]) { double sum = 0.0; int i, j; for (i=0; i < n; i++) { for (j=0; j < m; j++) { sum += x[i][j]; } } return sum; } and then call it from Python like this: import testc, Numeric x = Numeric.array([1.,2.,3.]) y = Numeric.array([6.,-1.,-1.]) z = Numeric.arange(6) *1.0 z.shape=(3,2) print "Should be 1.0:", testc.ctry(x,y) print "Should be sqrt(2) * [1,2,3]:", testc.cout(x) print "Should be 15.0:", testc.c2(z) z.shape=(2,3) print "Should be 15.0:", testc.c2(z) ----------- notes Somehow 7.0b1 was missing the C examples. I apparently lost the changes I had made to the MANIFEST and did not realize my CVS commits had failed. Bad day at the office, I guess. I added testc back in, and added a 2-dimensional example. I also eliminated some warning errors in the generated code, and fixed an error in that case. My thanks to Michiel de Hoon and J.S. Whitaker.

1 0

Python 2.2 seriously crippled for numerical computation?
by Huaiyu Zhu 23 Mar '02

23 Mar '02

There appears to be a serious bug in Python 2.2 that severely limits its usefulness for numerical computation: # Python 1.5.2 - 2.1 >>> 1e200**2 inf >>> 1e-200**2 0.0 # Python 2.2 >>> 1e-200**2 Traceback (most recent call last): File "<stdin>", line 1, in ? OverflowError: (34, 'Numerical result out of range') >>> 1e200**2 Traceback (most recent call last): File "<stdin>", line 1, in ? OverflowError: (34, 'Numerical result out of range') This produces the following serious effects: after hours of numerical computation, just as the error is converging to zero, the whole thing suddenly unravels. Note that try/except is completely useless for this purpose. I hope this is unintended behavior and that there is an easy fix. Have any of you experienced this? Huaiyu

7 12

adding a .M attribute to the array.
by Travis Oliphant 20 Mar '02

20 Mar '02

Recently there has been discussion on the list about the awkwardness of matrix syntax when using Numeric Python. Matrix expressions can be awkard to express in Numeric which is a negative mark on an otherwise excellent computing environment. Currently part of the problem can be solved by working with Matrix objects explicitly: a = Matrix.Matrix("[1 2 3; 4 5 6]") # Notice the strings. However, most operations return arrays which have to be recast to matrices using at best a character with parenthesis: M = Matrix.Matrix M(sin(a)) * M(cos(a)).T The suggestion was made to add ".M" as an attribute of arrays which returns a matrix. Thus, the code above can be written: sin(a).M * cos(a).M.T While some aesthestic simplicity is obtained, the big advantage is in consistency. Somebody else may decide that P = Matrix.Matrix is a better choice. But, if we establish that .M always returns a matrix for arrays < 2d, then we gain consistency. I've made this change and am ready to commit the change to the Numeric tree, unless there are strong objections. I know some people do not like the proliferation of attributes, but in this case the notational convenience it affords to otherwise overly burdened syntax and the consistency it allows Numeric to deal with Matrix equations may be worth it. What do you think? -Travis Oliphant

13 28

ANN: numarray-0.3
by Todd Miller 19 Mar '02

19 Mar '02

Numarray 0.3 ------------ Numarray is a Numeric replacement which features c-code generated from python template scripts, the capacity to operate directly on arrays in files, and improved type promotion semantics. Numarray-0.3 incorporates safety checks to prevent crashing Python when a user accidentally changes private variables in numarray. The new safety checks ensure that: 1. Numarray C-functions are called with properly sized buffers. 2. Numarray C-functions are called with properly aligned buffers. 3. Parameters match the C-function in count and i/o direction. 4. The correct generic function wrapper is used to call each C-function. 5. All indices implied by the array strides are valid. Failed checks result in python exceptions. A new memory object fixes an unforunate limitation of the python buffer object, namely the lack of guaranteed double aligned storage. The largest generated source module, _ufuncmodule.c, has been partitioned by data type into several smaller, more gcc-friendly modules, e.g. _ufuncFloat64module.c. The sort and argsort functions are fixed. The dot function is fixed for 1D arrays. Transpose, swapaxes, and reshape once again return views. WHERE ----------- Numarray-0.3 windows executable installers and source code tar ball is here: http://sourceforge.net/project/showfiles.php?group_id=1369 Numarray is hosted by Source Forge in the same project which hosts Numeric: http://sourceforge.net/projects/numpy/ The web page for Numarray information is at: http://stsdas.stsci.edu/numarray/index.html Trackers for Numarray Bugs, Feature Requests, Support, and Patches are at the Source Forge project for NumPy at: http://sourceforge.net/tracker/?group_id=1369 REQUIREMENTS -------------------------- numarray-0.3 requires Python 2.0 or greater. AUTHORS, LICENSE ------------------------------ Numarray was written by Perry Greenfield, Rick White, Todd Miller, JC Hsu, Paul Barrett, and Phil Hodge at the Space Telescope Science Institute. Numarray is made available under a BSD-style License. See LICENSE.txt in the source distribution for details. -- Todd Miller jmiller(a)stsci.edu <mailto:jmiller@stsci.edu> <mailto:jmiller@stsci.edu> STSCI / SSG (410) 338 4576 -- Todd Miller jmiller(a)stsci.edu STSCI / SSG (410) 338 4576

2 2

fft_help
by Karshi 16 Mar '02

16 Mar '02

Hi all, How do use Matlab like " fft_shift" in NumPy? Thanks

1 0

RE: [Numpy-discussion] Numerical Python 21.0 released
by Paul F Dubois 15 Mar '02

15 Mar '02

Gerard Vermeulen asked me to remove the RPMs from SourceForge, and I have done so. Apparently what is made by default is not useful except for me. I absolutely refuse to learn about RPMs; it is not useful for my job. If the RPM-cult wants this stuff to work then I need patches to setup.py that ALWAYS produce a suitable RPM, or a volunteer who will make and install such files for each release. I will run an automated test if supplied but it can't interfere with my system or require superuser privs, because I don't have that. I appreciate people trying to help and I'm sorry if it wasn't clear just how incompetent I intend to be on this.

3 2

Plans for RandomArray support in numarray?
by Amund Tveit 14 Mar '02

14 Mar '02

Are there any plans for supporting RandomArray in numarray type arrays? Amund http://www.idi.ntnu.no/~amundt/

2 1

Numerical Python 21.0 released
by Paul F Dubois 13 Mar '02

13 Mar '02

Version 21.0 March 13, 2002 Fixed bugs: [ #482603 ] Memory leak in MA/Numeric/Python Reported by Reggie Dugard. Turned out to be *two* memory leaks in one case in a routine in Numeric, array_objectype. (Dubois) [ none ] if vals was a null-array array([]) putmask and put would crash. Fixed with check. [ #469951 ] n = n1[0] gives array which shares dimension of n1 array. This causes bugs if shape of n1 is changed (n didn't used to have it's own dimensions array (Travis Oliphant) [ #514588 ] MLab.cov(x,x) != MLab.cov(x) (Travis Oliphant) [ #518702 ] segfault when invalid typecode for asarray (Travis Oliphant) [ #497530 ] MA __getitem__ prevents 0 len arrays (Reggie Duggard) [ #508363 ] outerproduct of noncontiguous arrays (Martin Wiechert) [ #513010 ] memory leak in comparisons (Byran Nollett) [ #512223 ] Character typecode not defined (Jochen Kupper) [ #500784 ] MLab.py diff error (anonymous, fixed by Dubois) [ #503741 ] accuracy of MLab.std(x) (Katsunori Waragai) [ #507568 ] overlapping copy a[2:5] = a[3:6] Change uses of memcpy to memmove which allows overlaps. [ numpy-Patches-499722 ] size of buffer created from array is bad (Michel Sanner). [ #502186 ] a BUG in RandomArray.normal (introduced by last bug fix in 20.3) (Katsunori Waragai). Fixed errors for Mac (Jack Jensen). Make rpm's properly, better Windows installers. (Gerard Vermeulen) Added files setup.cfg; setup calculates rpm_install.sh to use current Python. New setup.py, eliminate setup_all.py. Use os.path.join everywhere. Revision in b6 added file README.RPM, further improvements. Implement true division operations for Python 2.2. (Bruce Sherwood) Note: true division of all integer types results in an array of floats, not doubles. This decision is arbitrary and there are arguments either way, so users of this new feature should be aware that the decision may change in the future. New functions in Numeric; they work on any sequence a that can be converted to a Numeric array. Similar change to average in MA. (Dubois) def rank (a): "Get the rank of a (the number of dimensions, not a matrix rank)" def shape (a): "Get the shape of a" def size (a, axis=None): "Get the number of elements in a, or along a certain axis." def average (a, axis=0, weights=None, returned = 0): """average(a, axis=0, weights=None) Computes average along indicated axis. If axis is None, average over the entire array. Inputs can be integer or floating types; result is type Float. If weights are given, result is: sum(a*weights)/(sum(weights)) weights must have a's shape or be the 1-d with length the size of a in the given axis. Integer weights are converted to Float. Not supplying weights is equivalent to supply weights that are all 1. If returned, return a tuple: the result and the sum of the weights or count of values. The shape of these two results will be the same. raises ZeroDivisionError if appropriate when result is scalar. (The version in MA does not -- it returns masked values). """

1 0

big picture?
by eric 08 Mar '02

08 Mar '02

While we're discussing several big issues, it would be worthwhile to step back and get an idea of what people feel is still missing for numeric computation in the Python language and also what is missing from Numeric itself. I'm not talking about libraries here, but issues with notation and array functionality that you run into in day-to-day programming. Things are pretty dang good right now, but there are some areas (array indexing, matrix multiply, etc.) that some people see as sub-optimal or better implemented in other langauges. A list will provide a "big picture" of where we want to go (maybe we are there...) and also help us pick our battles on language changes, etc. So, what mathematical expressions are commonly used and yet difficult to write in Python? I don't mean integrals divergence, etc. I mean things like matrix multiply and transpose. Here is a beginning to the list: 1. Matrix Multiply -- should we ask for ~*? 2. Transpose -- In a perfect world, we'd have an operator for this. 3. complex conjugate -- An operator for this would also be welcomed. 4. Others?? These three have all been discussed on this list or on the SciPy list in the last month, so they are obvious. I don't think there is a solution for 2 and 3 besides using the current function or method calls (but they are still on my list). As I mentioned in my last post, 1 might be fixable. As far as core Numeric functionality: 1. Array indexing with arrays. 2. .M attributes -- an alternative to (1) in language changes. And I'll add a third, that I'd like. 3. tensor notation indexing as in the Blitz++ array library http://www.oonumerics.org/blitz/manual/blitz03.html#l75 NewAxis and Ellipses allow for the same functionality, but the tensor notation is much easier to read. This requires yet more indexing trickery though... Please limit this thread to language changes or Numeric enhancements. Desired changes to the current behavior or interface of Numeric should be saved for a different discussion. thanks, eric -- Eric Jones <eric at enthought.com> Enthought, Inc. [www.enthought.com and www.scipy.org] (512) 536-1057

7 10

Re: [Numpy-discussion] big picture? One proposal
by Konrad Hinsen 08 Mar '02

08 Mar '02

> The Python core has long had at least 2 examples of operators which > act as object constructors: 'j' which performs complex() and 'L' which > performs long() (you can't get much more `pythonic' than a built-in > type). Those are suffixes for constants, not operators. If they were operators, you could apply them to variables - which you can't. More importantly, the L suffix wouldn't even work as an operator, as the preceding number might extend the range of integers before it has a chance of being converted to a long integer. > I would venture to say that the numeric community is pretty high up > there in importance if not size, given the early appearance of the > complex number type and strong math capacity not to mention GvR's The complex type was introduced for the benefit of NumPy (I remember it all too well, as I did the initial implementation), but after a long discussion on the Python list, with many expressing disapprovement because of its special-need status. I'd say it shows the limits of what one can get accepted. Konrad. -- ------------------------------------------------------------------------------- Konrad Hinsen | E-Mail: hinsen(a)cnrs-orleans.fr Centre de Biophysique Moleculaire (CNRS) | Tel.: +33-2.38.25.56.24 Rue Charles Sadron | Fax: +33-2.38.63.15.17 45071 Orleans Cedex 2 | Deutsch/Esperanto/English/ France | Nederlands/Francais -------------------------------------------------------------------------------

1 0