Mailman 3 August 2002 - NumPy-Discussion

[Announce] Numerical Python 22.0
by Paul F Dubois 28 Aug '02

28 Aug '02

Numerical Python release 22.0 is at Sourceforge. A Windows installer and source zip are also available. Version 22.0 a. Changed multiarraymodule functions to accept keywords where documentation implies it through the use of optional variables. Specifically in multiarray: zeros, take, transpose, repeat, set_string_function, cross_correlate. in ufuncobject: reduce and accumulate now take keyword arguments for the optional axis argument. b. Added support for unsigned shorts 'w' and unsigned ints 'u' -- Travis Oliphant with help from Darren Hart and F. Oliver Gathmann. Increased max permissible iterations in SVD for supplied lapack. -- Dubois Recoded RandomArray.randint to try to see if we can work around bug on some platforms. -- Dubois Version 21.3 June 8, 2002 Fixed bugs: [ #557927 ] fixed matrix slice assignment [ #552922 ] added check for correct datatype in .astype() method. Created new API PyArray_ValidType to handle this check here as well as in multiarraymodule.c [ #551808 ] fixed segfault with unicode array (Travis O.) [ #559511 ] MLab.std now works for axis != 0 (Travis O.) [ #542979 ] sum returns exception tuple [ #528328 ] true division operators used to return single precision on division of integers and longs --- now defaults to double precision (but only on int and long division --- still single-precision for ubyte, short, and byte division. [ none ] arange(start, end, step) slightly different near end points than start + arange(0, N)*step where N is the length. [ none ] a = zeros(2,'D'); a[0] = array(0.0+0.6j) would not work. (Assigning a rank-0 array did not work for CFLOAT_setitem or CDOUBLE_setitem. [ 530688 ] Python crash when transposing array (Walter Moreira) 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

tensor ops in dim > 3?
by Dr. Dmitry Gokhman 28 Aug '02

28 Aug '02

I have a rank three n-dim tensor A. For two of the axes I want to perform v^t A v (a quadratic form with scalar output, where v is a vector). The final output should be a vector. I also need to compute the derivative of this with respect to v. This involves symmetrizing and matrix-vector multiplication (2 sym(A)v using two axes of A only, which gives a vector) with the final result being a matrix. Is there something elegant I can do short of extending numpy with fortrash routines? Perhaps something like SciPy's 3-d tensor ops but for n-dim? Thanks in advance for any tips, - d PS One more dumb question: I just installed the ScientificPython-2.4.1 rpm on my reincarnated Mandrake linux machine running python2.2. Do I need to do something to configure it? My scripts aren't finding things (e.g. indexing.py).

3 2

Re: numarray: RandomArray2
by Jochen Küpper 26 Aug '02

26 Aug '02

On Sun, 18 Aug 2002 08:13:18 -0400 Todd Miller wrote: Todd> Jochen Küpper wrote: >> Looking at RandomArray2 I realized that the functions don't do any >> argument checking. Shouldn't uniform for example check at least >> whether ,---- >> | minimum != maximum >> `---- >> or even make sure that maximum > minimum? (Although the result is >> probably "ok" if it isn't.) Something like >> ,---- >> | def uniform(minimum, maximum, shape=[]): >> | """Return array of random Floats in interval ]minimum, maximum[ >> | with shape |shape|. >> | """ >> | if maximum <= minimum: >> | raise ValueError >> | return minimum + (maximum-minimum)*random(shape) >> `---- >> Todd> I am +0 on this. The parameter order emulates "range". Not exactly, currently: ,---- | >>> range(2, -4) | [] | >>> ran.uniform(2, -4) | -2.2346744537353516 `---- That is, if max < min range returns an empty list, whereas uniform comes up with the same result as for (-4, 2) (well, "mirrored"). Also note the "strange" docstring of range: ,---- | range(...) | range([start,] stop[, step]) -> list of integers `---- pointing straight toward its behavior. Todd> While it does look like it will compute the wrong answer if Todd> called incorrectly, that seems unlikely to me. Well, if max<min it "mirrors" the result inside the range. This is no problem as long as it is done "consistently". I don't have enough knowledge of RNG's to understand whether it is a problem (with respect to randomness) when calls with the right and wrong ordering of min and max are mixed. Thinking about the case min==max I must say it's a very wasted function call, but no actually big deal: ,---- | >>> import RandomArray2 as ran | >>> ran.uniform(1, 1) | 1.0 `---- So well, maybe someone with insight into RNG's can comment on the, mirroring issue? >> Moreover there are some inconsistencies between functions, i.e.: >> ,---- >> | def randint(minimum, maximum=None, shape=[]): >> `---- >> ,---- >> | def random_integers(maximum, minimum=1, shape=[]): >> `---- Todd> It appears to me that the parameter order of randint again Todd> emulates "range". The fact that random_integers is not Todd> consistent with randint seem OK to me because random_integers Todd> appears to have been written expressly to tailor the calling Todd> sequence of randint. Hmm, v.s. Yes, initially I wondered why there are two functions at all. This explanation sounds like "we wanted some help in confusing the users" :)) Todd> Because randint re-defines its parameters depending on whether 1 Todd> or 2 range values are used, as does range, I don't think there Todd> is a completely consistent way to do this. Either we're "wrong" Todd> for the 1 parameter case or the 2 parameter case. The way it is Todd> specified now seems simplest to me, with "minimum" preceding Todd> "maximum", even though it is not strictly the correct name for Todd> the 1 parameter case. What's about ,---- | uniform(limit1, limit2, shape=[]) `---- and then range-like behaviour? But then, what do we return on ,---- | uniform(2, -4) `---- ??? To make it compatible with range, it should be an empty list, no? Your-even-more-confused-ly's, Jochen -- Einigkeit und Recht und Freiheit http://www.Jochen-Kuepper.de Liberté, Égalité, Fraternité GnuPG key: 44BCCD8E Sex, drugs and rock-n-roll

3 3

numarray, Convolve, and lineshapes
by Jochen Küpper 22 Aug '02

22 Aug '02

Looking at Convolve last night I came up with the idea that we often need to convolute datasets with common profiles, such as Gauss- or Voigt-lineshapes, for example. So tonight I took my old module I had for that purpose apart and put it as submodule into Convolve. Well, currently it really only supports Gauss, Lorentz, and Voigt, but the general "framework" to add more profiles is there. Adding a new one would consist of defining a new derived class (overall 5 lines of code) and providing a function that calculates the actual line profile. I chose the implementation using functor classes so profiles can be reused. I am aware that there are some issues with the functions in Lineshape.py (error checking, not automatically converting sequences to arrays, ...). If this is a way to go I would move the functions to C anyway. Nevertheless a sample function in Python will be provided, so new profiles can easily added without caring about C. I would like to get some feedback whether you think this should be included in numarray. I believe it fits very well into Convolve. Example use: import numarray as num import random as ran import Convolve import Convolve.Lineshape as ls resolution = 0.1 fwhm = 0.5 # get some (random) data, i.e. a stick-spectrum x = num.arange(-50, 50+resolution, resolution) y = num.zeros(x.shape, num.Float) for i in range(10): y[ran.randint(0, len(y)-1)] = ran.random() # create lineshape objects g = ls.GaussProfile(num.arange(-10*fwhm, 10*fwhm+resolution, resolution), 1.0) v = ls.VoigtProfile(num.arange(-10*fwhm, 10*fwhm+resolution, resolution), (0.6, 0.6)) # convolute data with profile res_g = Convolve.convolve(y, g(), Convolve.SAME) res_v = Convolve.convolve(y, v(), Convolve.SAME) for i in zip(x, y, res_g, res_v): print "%12.6f %12.6f %12.6f %12.6f" % i I attach an archive of the whole Convolve/ dir here in my local copy. Greetings, Jochen -- Einigkeit und Recht und Freiheit http://www.Jochen-Kuepper.de Liberté, Égalité, Fraternité GnuPG key: 44BCCD8E Sex, drugs and rock-n-roll

3 3

numarray -- correlate
by Jochen Küpper 21 Aug '02

21 Aug '02

Is there any good reason to not rename Convolve.cross_correlate to correlate? That fits the other names much better. If needed (aka backwards-compatibility to numpy) we could even provide an alias cross_correlate -- probably documented to be deprecated... But since you have to load a separate module anyway, I think we can rename the function just as well. Greetings, Jochen -- Einigkeit und Recht und Freiheit http://www.Jochen-Kuepper.de Liberté, Égalité, Fraternité GnuPG key: 44BCCD8E Sex, drugs and rock-n-roll

2 2

Cygwin floating point control
by Jochen Küpper 20 Aug '02

20 Aug '02

The following program does not link on Cygwin ,---- | #include <ieeefp.h> | | int main() | { | return(fgetsticky()); | } `---- due to fpgetsticky beeing unresolved. fpgetsticky is declared in /usr/include/ieeefp.h, but I cannot find any library it is defined in. A search on the Cywin site and at google didn't turn up anything for fpgetsticky on Cygwin. (?) Is it implemented? If so, where? If not, is there any substitute I should be using? Greetings, Jochen PS: It would be nice if you could cc me. -- University of North Carolina phone: +1-919-962-4403 Department of Chemistry phone: +1-919-962-1579 Venable Hall CB#3290 (Kenan C148) fax: +1-919-843-6041 Chapel Hill, NC 27599, USA GnuPG key: 44BCCD8E

2 1

numarray on Cygwin
by Jochen Küpper 19 Aug '02

19 Aug '02

Hi, I could succesfully compile numarray (see numpy.org) on Cygwin (updated last week), using the standard Cygwin python. However many tests fail, due to "missing" overflow or "division by zero" exceptions. I took a quick look at the test-failures of numarray on numpy. The first problem is that we don't get a "Overflow error" warning when it is expected: ,----[Cygwin] | >>> array([1, 8, 100, 100], type=Int8) * array([1, 8, 100, -100], type=Int8) | array([ 1, 64, 127, -128], type=Int8) `---- Whereas on Linux we get ,----[Linux] | >>> array([1, 8, 100, 100], type=Int8) * array([1, 8, 100, -100], type=Int8) | Warning: Encountered overflow(s) in multiply | array([ 1, 64, 127, -128], type=Int8) `---- Is this related to a configuration option of python (--with-sigfpe ?) or a "feature" of the Cygwin libm/libc? Any ideas? Btw, I tried to rebuild python (cvs maint22-release patched for _socket) but got the following errors with the math module (similar for cmath): ,---- | gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mathmodule.o -L/usr/local/lib -L. -lm -lpython2.2 -o build/lib.cygwin-1.3.12-i686-2.2/math.dll | build/temp.cygwin-1.3.12-i686-2.2/mathmodule.o: In function `math_1': | /home/software/programming/compiler/python/dist/src/Modules/mathmodule.c:57: undefined reference to `PyFPE_counter' | /home/software/programming/compiler/python/dist/src/Modules/mathmodule.c:57: undefined reference to `PyFPE_counter' | /home/software/programming/compiler/python/dist/src/Modules/mathmodule.c:57: undefined reference to `PyFPE_jbuf' | /home/software/programming/compiler/python/dist/src/Modules/mathmodule.c:57: undefined reference to `PyFPE_counter' | /home/software/programming/compiler/python/dist/src/Modules/mathmodule.c:59: undefined reference to `PyFPE_dummy' | /home/software/programming/compiler/python/dist/src/Modules/mathmodule.c:59: undefined reference to `PyFPE_counter' | build/temp.cygwin-1.3.12-i686-2.2/mathmodule.o: In function `math_2': | /home/software/programming/compiler/python/dist/src/Modules/mathmodule.c:74: undefined reference to `PyFPE_counter' | /home/software/programming/compiler/python/dist/src/Modules/mathmodule.c:74: undefined reference to `PyFPE_counter' | /home/software/programming/compiler/python/dist/src/Modules/mathmodule.c:74: undefined reference to `PyFPE_jbuf' | /home/software/programming/compiler/python/dist/src/Modules/mathmodule.c:74: undefined reference to `PyFPE_counter' | /home/software/programming/compiler/python/dist/src/Modules/mathmodule.c:76: undefined reference to `PyFPE_dummy' | /home/software/programming/compiler/python/dist/src/Modules/mathmodule.c:76: undefined reference to `PyFPE_counter' | build/temp.cygwin-1.3.12-i686-2.2/mathmodule.o: In function `math_ldexp': | /home/software/programming/compiler/python/dist/src/Modules/mathmodule.c:173: undefined reference to `PyFPE_counter' | /home/software/programming/compiler/python/dist/src/Modules/mathmodule.c:173: undefined reference to `PyFPE_counter' | /home/software/programming/compiler/python/dist/src/Modules/mathmodule.c:173: undefined reference to `PyFPE_jbuf' | /home/software/programming/compiler/python/dist/src/Modules/mathmodule.c:173: undefined reference to `PyFPE_counter' | /home/software/programming/compiler/python/dist/src/Modules/mathmodule.c:175: undefined reference to `PyFPE_dummy' | /home/software/programming/compiler/python/dist/src/Modules/mathmodule.c:175: undefined reference to `PyFPE_counter' | collect2: ld returned 1 exit status | WARNING: building of extension "math" failed: command 'gcc' failed with exit status 1 `---- Greetings, Jochen -- University of North Carolina phone: +1-919-962-4403 Department of Chemistry phone: +1-919-962-1579 Venable Hall CB#3290 (Kenan C148) fax: +1-919-843-6041 Chapel Hill, NC 27599, USA GnuPG key: 44BCCD8E

1 0

Re: numarray
by Jochen Küpper 19 Aug '02

19 Aug '02

On Sun, 18 Aug 2002 08:21:20 -0400 Todd Miller wrote: >> The following patch is required for Cygwin: >> >> Index: Src/_chararraymodule.c >> Todd> I'll apply this. Applied. >> ,---- >> | ***************************************************************** >> | Failure in example: >> | array([1, 8, 100, 100], type=Int8) * array([1, 8, 100, -100], type=Int8) >> | from line #1671 of numtest >> | Expected: >> | Warning: Encountered overflow(s) in multiply >> | array([ 1, 64, 127, -128], type=Int8) >> | Got: array([ 1, 64, 127, -128], type=Int8) >> | ***************************************************************** >> `---- Todd> This overflow exception issue came up earlier this year with Todd> IRIX. My guess is that the function int_overflow_error() in Todd> codegenerator.py is not working correctly. The suggested Todd> temporary patch at the time was: [patch against codegenerator.py] Todd> If you try it out and it solves the problem for Cygwin, we Todd> should probably change it universally. No, it doesn't solve the problem. I hope to find some time later this week to look at it. Greetings, Jochen -- University of North Carolina phone: +1-919-962-4403 Department of Chemistry phone: +1-919-962-1579 Venable Hall CB#3290 (Kenan C148) fax: +1-919-843-6041 Chapel Hill, NC 27599, USA GnuPG key: 44BCCD8E

1 0

Pyrex now interfaces with NumPy (old) array internals
by Frank Horowitz 18 Aug '02

18 Aug '02

Perhaps this is best left to Greg Ward, but I just thought that I'd point out to the list that Pyrex <http://www.cosc.canterbury.ac.nz/~greg/python/Pyrex/> in the latest version 0.4.1 successfully interfaces with the (original) Numeric array data types. There are examples in both the Demo subdirectory and in the website's FAQ. Another alternative for getting performance, interfacing to C libraries, and even calling Fortran (from Pyrex's Python/C hybrid code). Frank (Choice is Good ;-) Horowitz

1 0

[ANNOUNCE] Pyfort 8.2 and video tutorials for Python, Pyfort
by Paul F Dubois 15 Aug '02

15 Aug '02

Pyfortran 8.2 is available. The setup bug for Windows is fixed and a -n option has been added to just generate glue code and stop. Video tutorials are now available at http://esg.llnl.gov/cdat/ (go to documentation and tutorials). There are instructions online about how to set up your computer to play these videos. The Linux instructions may or may not work for you; for the moment we recommend viewing from Windows. These tutorials are mostly for CDAT users, but there are two for Pyfort and one short "Introduction to Python". Our most excellent summer student from USC, Tasha Drew, got everything working.

1 0