Mailman 3 February 2007 - NumPy-Discussion

numpy.matlib.abs
by Keith Goodman 06 Feb '07

06 Feb '07

There's a numpy.abs but no numpy.matlib.abs. >> import numpy as N >> import numpy.matlib as M >> >> N.abs? Type: ufunc Base Class: <type 'numpy.ufunc'> String Form: <ufunc 'absolute'> Namespace: Interactive Docstring: y = absolute(x) takes |x| elementwise. >> M.abs? Object `M.abs` not found.

3 4

NumPy compatible version of ScientificPython
by Jarrod Millman 06 Feb '07

06 Feb '07

The current development release of ScientificPython (2.7.3) supports NumPy. The release notes are here: http://sourcesup.cru.fr/frs/shownotes.php?release_id=634 I updated the "Porting to NumPy" wiki page: http://www.scipy.org/Porting_to_NumPy -- Jarrod Millman Computational Infrastructure for Research Labs 10 Giannini Hall, UC Berkeley phone: 510.643.4014 http://cirl.berkeley.edu/

1 0

Fwd: [Rpy] status of numpy version of rpy
by Jarrod Millman 06 Feb '07

06 Feb '07

Hey, After reading Travis' email about getting more projects ported to Numpy, I sent an email to the RPy developer's asking when they would commit Travis' patch. Anyway, George Warnes replied that he would apply it this week (see the forwarded email below). I would encourage anyone who is using a project that hasn't converted to Numpy to send the developer's an email letting them know that you want them to move the project to Numpy as soon as possible. Thanks to all the Numpy developers, and in particular to Travis, for working so hard to make Numpy so great. Jarrod ---------- Forwarded message ---------- From: Gregory. R. Warnes <greg(a)warnes.net> Date: Feb 5, 2007 7:33 AM Subject: Re: [Rpy] status of numpy version of rpy To: "RPy help, support and design discussion list" <rpy-list(a)lists.sourceforge.net> Hi Jarrod, The Numpy patch should be applied sometime this week. -Greg On Feb 3, 2007, at 3:03 AM, Jarrod Millman wrote: > Hello, > > Thanks for all the great work. I am involved with the Neuroimaging in > Python project, which uses numpy. Numpy is very stable and much > better than Numeric. The problem is that some of us are also using > RPy for our data processing. So we are using Travis' numpy patch for > RPy. It seems to work perfectly. This process is acceptable for our > developers, but creates additional installation headaches for our > regular users. > > Do you have a timeline for when you will apply the numpy patch? Is > there anything you need help with before applying the patch? > > Thanks, > > -- > Jarrod Millman > Computational Infrastructure for Research Labs > 10 Giannini Hall, UC Berkeley > phone: 510.643.4014 > http://cirl.berkeley.edu/ > > ---------------------------------------------------------------------- > --- > Using Tomcat but need to do more? Need to support web services, > security? > Get stuff done quickly with pre-integrated technology to make your > job easier. > Download IBM WebSphere Application Server v.1.0.1 based on Apache > Geronimo > http://sel.as-us.falkag.net/sel? > cmd=lnk&kid=120709&bid=263057&dat=121642 > _______________________________________________ > rpy-list mailing list > rpy-list(a)lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/rpy-list ------------------------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier. Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 _______________________________________________ rpy-list mailing list rpy-list(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rpy-list -- Jarrod Millman Computational Infrastructure for Research Labs 10 Giannini Hall, UC Berkeley phone: 510.643.4014 http://cirl.berkeley.edu/

1 0

FFT definition
by Hanno Klemm 05 Feb '07

05 Feb '07

Hi there, I have a question regarding the definitions surrounding FFTs. The help to numpy.fft.fft says: >>> help(N.fft.fft) Help on function fft in module numpy.fft.fftpack: fft(a, n=None, axis=-1) fft(a, n=None, axis=-1) Will return the n point discrete Fourier transform of a. n defaults to the length of a. If n is larger than a, then a will be zero-padded to make up the difference. If n is smaller than a, the first n items in a will be used. The packing of the result is "standard": If A = fft(a, n), then A[0] contains the zero-frequency term, A[1:n/2+1] contains the positive-frequency terms, and A[n/2+1:] contains the negative-frequency terms, in order of decreasingly negative frequency. So for an 8-point transform, the frequencies of the result are [ 0, 1, 2, 3, 4, -3, -2, -1]. This is most efficient for n a power of two. This also stores a cache of working memory for different sizes of fft's, so you could theoretically run into memory problems if you call this too many times with too many different n's. >>> However, the help to numpy.fft.helper.fftfreq says: >>> help(N.fft.helper.fftfreq) Help on function fftfreq in module numpy.fft.helper: fftfreq(n, d=1.0) fftfreq(n, d=1.0) -> f DFT sample frequencies The returned float array contains the frequency bins in cycles/unit (with zero at the start) given a window length n and a sample spacing d: f = [0,1,...,n/2-1,-n/2,...,-1]/(d*n) if n is even f = [0,1,...,(n-1)/2,-(n-1)/2,...,-1]/(d*n) if n is odd >>> So one claims, that the packing goes from [0,1,...,n/2,-n/2+1,..,-1] (fft) and the other one claims the frequencies go from [0,1,...,n/2-1,-n/2,...-1] Is this inconsistent or am I missing something here? Hanno -- Hanno Klemm klemm(a)phys.ethz.ch

3 4

Memory leak in argsort?
by Keith Goodman 05 Feb '07

05 Feb '07

This eats up memory quickly on my system. import numpy.matlib as M def memleak(): a = M.randn(500, 1) while True: a = a.argsort(0)

3 3

python eats memory like the cookie monster eats cookies
by Niels Provos 05 Feb '07

05 Feb '07

Good morning, not sure if I got the right list, but I hope that somebody here will be able to shed some light on a Python-related memory problem. The following code eats over >2GB of memory and fails with MemoyError after just a few iterations. def ZeroPadData(A, shape): a = Numeric.zeros(shape, 'w') a.savespace() for y in xrange(A.shape[0]): for x in xrange(A.shape[1]): a[y, x] = A[y, x] return a def EatMemoryLikeTheCookieMonster(limit=10): A = Numeric.ones([1998, 3022]) count = 0 a = A while count < limit: print count count += 1 a = ZeroPadData(a, [2048, 4096]) b = fft2(a) b = ifft2(b) a = b[:1998,:3022].real EatMemoryLikeTheCookieMonster() This is for Python 2.4.3 on Mac OS X 10.4.8 (intel) using SciPy 0.5.2. If anyone could enlighten me about what I am doing wrong, I would very much appreciate it. Thank you, Niels.

3 6

Re: [Numpy-discussion] r3530 breaks nan_to_num for complex64 arrays
by Tim Leslie 05 Feb '07

05 Feb '07

On 2/5/07, Tim Leslie <tim.leslie(a)gmail.com> wrote: > Hi All, > > As of svn revision 3530 N.nan_to_num no longer works for arrays of > complex64. The actual error is raised in the signbit function, but I'm > not sure why this is failing. If someone has a quick fix for this > that'd be great, if not I'll lodge a full bug report when I get back > from lunch :-). Just noticed that this has already been reported. http://projects.scipy.org/scipy/numpy/ticket/443 Cheers, Tim > > Cheers, > > Tim > > In [1]: import numpy as N > > In [2]: a = N.ones((10, 10, 10), N.complex64) > > In [3]: N.nan_to_num(a) > --------------------------------------------------------------------------- > exceptions.TypeError Traceback (most > recent call last) > > /home/timl/<ipython console> > > /usr/lib/python2.4/site-packages/numpy/lib/type_check.py in nan_to_num(x) > 130 else: > 131 scalar = False > --> 132 are_inf = isposinf(y) > 133 are_neg_inf = isneginf(y) > 134 are_nan = isnan(y) > > /usr/lib/python2.4/site-packages/numpy/lib/ufunclike.py in isposinf(x, y) > 31 if y is None: > 32 y = empty(x.shape, dtype=nx.bool_) > ---> 33 umath.logical_and(isinf(x), ~signbit(x), y) > 34 return y > 35 > > TypeError: function not supported for these types, and can't coerce > safely to supported types >

1 0

numpy.tests() FAILED (errors=3)
by Xavier Gnata 04 Feb '07

04 Feb '07

Hi, I'm using numpy svn and running numpy.test(). The error log is the following : ====================================================================== ERROR: check_complex_bad (numpy.lib.tests.test_type_check.test_nan_to_num) ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/lib/python2.4/site-packages/numpy/lib/tests/test_type_check.py", line 245, in check_complex_bad vals = nan_to_num(v) File "/usr/lib/python2.4/site-packages/numpy/lib/type_check.py", line 132, in nan_to_num are_inf = isposinf(y) File "/usr/lib/python2.4/site-packages/numpy/lib/ufunclike.py", line 33, in isposinf umath.logical_and(isinf(x), ~signbit(x), y) TypeError: function not supported for these types, and can't coerce safely to supported types ====================================================================== ERROR: check_complex_bad2 (numpy.lib.tests.test_type_check.test_nan_to_num) ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/lib/python2.4/site-packages/numpy/lib/tests/test_type_check.py", line 253, in check_complex_bad2 vals = nan_to_num(v) File "/usr/lib/python2.4/site-packages/numpy/lib/type_check.py", line 132, in nan_to_num are_inf = isposinf(y) File "/usr/lib/python2.4/site-packages/numpy/lib/ufunclike.py", line 33, in isposinf umath.logical_and(isinf(x), ~signbit(x), y) TypeError: function not supported for these types, and can't coerce safely to supported types ====================================================================== ERROR: check_complex_good (numpy.lib.tests.test_type_check.test_nan_to_num) ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/lib/python2.4/site-packages/numpy/lib/tests/test_type_check.py", line 238, in check_complex_good vals = nan_to_num(1+1j) File "/usr/lib/python2.4/site-packages/numpy/lib/type_check.py", line 132, in nan_to_num are_inf = isposinf(y) File "/usr/lib/python2.4/site-packages/numpy/lib/ufunclike.py", line 33, in isposinf umath.logical_and(isinf(x), ~signbit(x), y) TypeError: function not supported for these types, and can't coerce safely to supported types ---------------------------------------------------------------------- It should be a side effect of one patch because I can read things like " # !! This is actually (unexpectedly) zero" in /usr/lib/python2.4/site-packages/numpy/lib/tests/test_type_check.py Xavier. -- ############################################ Xavier Gnata CRAL - Observatoire de Lyon 9, avenue Charles André 69561 Saint Genis Laval cedex Phone: +33 4 78 86 85 28 Fax: +33 4 78 86 83 86 E-mail: gnata(a)obs.univ-lyon1.fr ############################################

1 0

Native byteorder representation
by Francesc Altet 04 Feb '07

04 Feb '07

Hi, We have been bitten by a small glitch related with the representation of native byteorders. Here is an example exposing the problem: >>> numpy.dtype('<i4').byteorder '=' >>> numpy.dtype('>i4').newbyteorder('little').byteorder '<' [the example was run on a little endian machine] We thought that native byteorder were represented always by a '=', and this is true when you create the type from scratch. But, if you create a dtype with a different byteorder and then switch to a native one (in this case, 'little') the representation of the byteorder changes to '<' instead of '='. We can live with this, but IMO it would be better if the final representation of native byteorders could always be made to read '='. Thanks, -- >0,0< Francesc Altet http://www.carabos.com/ V V Cárabos Coop. V. Enjoy Data "-"

7 13

classmethods for ndarray
by Travis Oliphant 03 Feb '07

03 Feb '07

What is the attitude of this group about the ndarray growing some class methods? I'm thinking that we should have several. For example all the fromXXX functions should probably be classmethods ndarray.frombuffer ndarray.fromfile etc. -Travis

9 13