Mailman 3 January 2005 - NumPy-Discussion

Re: [Numpy-discussion] ScientificPython with numarray support
by Gary Ruben 14 Jan '05

14 Jan '05

Hi Sebastian, You could also use the linregress function in scipy.stats if you're doing least squares fitting of a straight line. Gary R. ----- Original Message ----- > On Friday 14 January 2005 04:15 pm, John Hunter wrote: > > >>>>> "Sebastian" == Sebastian Haase <haase(a)msg.ucsf.edu> writes: > > > > Sebastian> The LeastSquare-fit is exactly what I'm interested in, > > Sebastian> since I couldn't find something similar anywhere else > > Sebastian> (like: It's not in SciPy, right?) > > > > best, info, ier, mesg = leastsq(errfunc, guess, full_output=1) > > Thanks John, > I thought it should be there. > Is the code / algorithm about similar to what Konrad has in Scientific ? > > - Sebastian -- ___________________________________________________________ Sign-up for Ads Free at Mail.com http://promo.mail.com/adsfreejump.htm

1 0

Simplifying array()
by Todd Miller 14 Jan '05

14 Jan '05

Someone (way to go Rory!) recently posted a patch (woohoo!) for numarray which I think bears a little discussion since it involves the re-write of a fundamental numarray function: array(). The patch fixes a number of bugs and deconvolutes the logic of array(). The patch is here if you want to look at it yourself: http://sourceforge.net/tracker/?atid=450449&group_id=1369&func=browse One item I thought needed some discussion was the removal of two features: > * array() does too much. E.g., handling file/memory instances for > 'sequence'. There's fromfile for the former, and users needing > the latter functionality should be clued up enough to > instantiate NumArray directly. I agree with this myself. Does anyone care if they will no longer be able to construct an array from a file or buffer object using array() rather than fromfile() or NumArray(), respectively? Is a deprecation process necessary to remove them? I think strings.py and records.py also have "over-stuffed" array() functions... so consistency bids us to streamline those as well. Regards, Todd

9 12

iterating over an array
by Ralf Juengling 14 Jan '05

14 Jan '05

Hi, I have an application where I cannot avoid (afaikt) looping over one array dimension. So I thought it might help speeding up the code by setting up the data in a way so that the dimension to loop over is the first dimension. This allows to write for data in a: do sth with data instead of for i in range(len(a)): data = a[i] do sth with data and would save the indexing operation. To my surprise it didn't make a difference in terms of speed. A little timing experiment suggests, that the first version is actually slightly slower than the second: >>> setup = 'import numarray as na; a = na.arange(2000,shape=(1000,2))' >>> Timer('for row in a: pass', setup).timeit(number=1000) 13.495718955993652 >>> Timer('for i in range(len(a)): row=a[i]', setup).timeit(number=1000) 12.162748098373413 I noticed that the array object does not have a special method __iter__, so apparently, no attempts have been made so far to make array iteration fast. Do you think it's possible to speed things up by implementing an __iter__ method? This is high on my wish list and I would help with implementing it, appreciating any advice. Thanks, Ralf

4 4

Re: [Numpy-discussion] iterating over an array
by Todd Miller 14 Jan '05

14 Jan '05

On Fri, 2005-01-14 at 09:28 +0100, Francesc Altet wrote: > A Dijous 13 Gener 2005 23:57, Chris Barker va escriure: > > >>> setup = 'import Numeric as na; a = na.arange(2000);a.shape= (1000,2)' > > >>> Timer('for i in range(len(a)): row=a[i]', setup).timeit (number=1000) > > 1.97064208984375 > > >>> setup = 'import numarray as na; a = na.arange(2000);a.shape= (1000,2)' > > >>> Timer('for i in range(len(a)): row=a[i]', setup).timeit (number=1000) > > 27.220904111862183 > > > > yup! that's it. numarray's indexing is SLOW. So it's not an iterator > > issue. Look in the archives of this list for discussion of why > > numarray's generic indexing is slow. A search for "wxPython indexing" > > will probably turn it up. > > Well, if you want to really compare generic indexing speed, you can't mix > array creation objects in the process, as your example seems to do. > > A pure indexing access test would look like: > > >>> setup = 'import numarray as na; a = [i*2 for i in range(2000)]' > >>> Timer('for i in range(len(a)): row=a[i]', setup).timeit (number=1000) > 0.48835396766662598 # With Python Lists > >>> setup = 'import Numeric as na; a = na.arange(2000);a.shape= (1000*2,)' > >>> Timer('for i in range(len(a)): row=a[i]', setup).timeit (number=1000) > 0.65753912925720215 # With Numeric > >>> setup = 'import numarray as na; a = na.arange(2000);a.shape= (1000*2,)' > >>> Timer('for i in range(len(a)): row=a[i]', setup).timeit (number=1000) > 0.89093804359436035 # With numarray > > That shows that numarray indexing is slower than Numeric, but not by a large > extent (just a 40%). The real problem with numarray (for Ralf's example) is, > as is already known, array creation time. I thought we were done after what Francesc pointed out above, then I tried this: from timeit import Timer setup = 'import numarray as na; a = na.arange(2000,shape=(2000,))' print "numarray iteration: ", Timer('for i in a: pass', setup).timeit(number=1000) print "numarray simple indexing, int value:", Timer('for i in range(len(a)): row=a[i]', setup).timeit(number=1000) setup = 'import Numeric as na; a = na.arange(2000); a.shape=(2000,)' print "Numeric iteration: ", Timer('for i in a: pass', setup).timeit(number=1000) print "Numeric simple indexing, int value:", Timer('for i in range(len(a)): row=a[i]', setup).timeit(number=1000) And got: numarray iteration: 8.81474900246 numarray simple indexing, int value: 3.61732387543 Numeric iteration: 1.0384759903 Numeric simple indexing, int value: 2.18056321144 This is running on Python-2.3.4 compiled --with-debug using gcc-3.4.2 on a 1 GHZ Athlon XP and FC3 Linux. Simple indexing returning an int was 66% slower for me, but iteration was 880% slower. It looks to me like there is room for significant numarray iteration improvement; I'm not sure how it needs to be done or if Numeric has any special support. Regards, Todd

1 0

Numeric 23.6 for Python 2.4 (23.7 anyone)
by D. Bahi 13 Jan '05

13 Jan '05

Hey this works for me! Thanks very much Jonathan. Want to do it again for 23.7? das __________________________________ Do you Yahoo!? All your favorites on one personal page � Try My Yahoo! http://my.yahoo.com

1 0

position of objects?
by Bob Klimek 13 Jan '05

13 Jan '05

Hi, Is there a way to obtain the positions (coordinates) of objects that were found with find_objects() function (in nd_image)? Specifically what I'm looking for is the coordinates of the bounding box (for a 2d array it would be upper-left and lower-right). Regards, Bob

2 1

Matrix-SIG archives
by Robert Kern 12 Jan '05

12 Jan '05

It looks like the mailing list archives for the Matrix-SIG and other retired SIGs are down at the moment. I've alerted the python.org webmaster, but in the meantime, does anyone have the early archives sitting around somewhere? I'm trying to answer a question about the motivations of a particular design decision in Numeric (why dot(A,B) doesn't do conjugation on A when A is complex). Thanks in advance. -- Robert Kern rkern(a)ucsd.edu "In the fields of hell where the grass grows high Are the graves of dreams allowed to die." -- Richard Harter

2 1

numarray dotblas
by Jochen Küpper 12 Jan '05

12 Jan '05

I needed the following patch to build _dotblas on a fresh system: ,---- | Index: Src/_dotblas.c | =================================================================== | RCS file: /cvsroot/numpy/numarray/Src/_dotblas.c,v | retrieving revision 1.2 | diff -u -u -r1.2 _dotblas.c | --- Src/_dotblas.c 5 Jan 2005 19:57:08 -0000 1.2 | +++ Src/_dotblas.c 12 Jan 2005 17:16:12 -0000 | @@ -10,8 +10,8 @@ | | | #include "Python.h" | -#include "numarray/libnumarray.h" | -#include "numarray/arrayobject.h" | +#include "libnumarray.h" | +#include "arrayobject.h" | #include <cblas.h> | | #include <stdio.h> `---- Alternatively -IInclude must be added to the compile flags (setup.py: headers()). Greetings, Jochen -- Einigkeit und Recht und Freiheit http://www.Jochen-Kuepper.de Liberté, Égalité, Fraternité GnuPG key: CC1B0B4D (Part 3 you find in my messages before fall 2003.)

2 1

A request for new distributions
by Jack Jansen 10 Jan '05

10 Jan '05

I'm catching up with half a year of back postings on the numpy list, and the messages about automatically using vecLib on the macintosh sound very interesting. I maintain the official Package Manager databases for MacPython (which allow users to install a handful of common packages with one mouseclick), and Numeric and numarray have been in there since day one. I'm revising all the packages again at the moment (I do that about once a year, or on request), and I had to manually fiddle Numeric 23.6 to actually build on the Mac. This is a bit of a bother, as I have to keep a separate source distribution in stead of just referring to the official one, but more important is the fact that neither Numeric nor numarray support vecLib out of the box. So, a plea for help: I don't know what the usual frequency for Numeric and numarray distributions is, but it would be very helpful for me (and for anyone using Numeric/numarray on the Mac) if new distributions were available that contained the fixes mentioned in the november discussions... -- Jack Jansen, <Jack.Jansen(a)cwi.nl>, http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman

8 14

ImportError
by René Bastian 07 Jan '05

07 Jan '05

Hi, I use python2.4+numarray1.1.1. import numarray.convolve as conv produces an ImportError : No module named convolve Can you help me ? -- René Bastian http://www.musiques-rb.org : Musique en Python

2 5