Mailman 3 March 2006 - NumPy-Discussion

Is sum() slow?
by Mads Ipsen 08 Mar '06

08 Mar '06

Hi, Sorry if this is a double post - unsure if it made it the first time: Here are some timings that puzzle me a bit. Sum the two rows of a 2xn matrix, where n is some large number python -m timeit -s "from numpy import array,sum,reshape; x = array([1.5]*1000); x = reshape(x,(2,500))" "x.sum(0)" 10000 loops, best of 3: 36.2 usec per loop python -m timeit -s "from numpy import array,sum,reshape; x = array([1.5]*1000); x = reshape(x,(2,500))" "x[0] + x[1]" 100000 loops, best of 3: 5.35 usec per loop The two calculations are completely equivalent (at least from the numerical results point of view). But using the built-in sum() function is app. 6 times slower. Just for the reference - using Numeric gives python -m timeit -s "from Numeric import array,sum,reshape; x = array([1.5]*1000); x = reshape(x,(2,500))" "sum(x)" 100000 loops, best of 3: 7.08 usec per loop Any suggestions to why this might be - or am I doing something wrong here? Thanks // Mads PS. Thanks to everybody that responded to my previous posting on problems and questions regarding rint() and related coding issues. Your replies were very helpful!

4 3

Fw: numpy-discussion
by dimgmdrp 08 Mar '06

08 Mar '06

----- Original Message ----- From: Burr Colin To: uemyevc(a)flowserve.com Sent: Monday, March 6, 2006 9:30 AM Subject: numpy-discussion

1 0

Matrix times scalar is wacky
by Bill Baxter 08 Mar '06

08 Mar '06

Multiplying a matrix times a scalar seems to return junk for some reason: >>> A = numpy.asmatrix(numpy.rand(1,2)) >>> A matrix([[ 0.30604211, 0.98475225]]) >>> A * 0.2 matrix([[ 6.12084210e-002, 7.18482614e-290]]) >>> 0.2 * A matrix([[ 6.12084210e-002, 7.18482614e-290]]) >>> numpy.__version__ '0.9.5' --billyb

6 9

asin, acos, etc...
by Nikhil Padmanabhan 08 Mar '06

08 Mar '06

Hi, Is there support for the inverse trigonometric functions in numpy? I haven't been able to find any references in the documentation, but I might have not been looking hard enough. I am using v0.9.4. Thanks in advance, -- Nikhil ------------------------------------ Nikhil Padmanabhan nikhil.padmanabhan(a)gmail.com

2 2

Power optimization branch merged to Numpy trunk
by cookedm＠physics.mcmaster.ca 08 Mar '06

08 Mar '06

Since Tim and I are now fiddling around with numexpr, I've merged what we've got with the power optimization to the Numpy trunk. This includes: * x**2 is _as_fast_ as x*x now * optimization of x**n for x as an array and n as a Python scalar. * x**2, x**(-1), x**0 are optimized to use the new square, reciprocal, and ones_like ufuncs * complex integer powers should be faster Also, PyArray_FromAny has been speeded up when converting Python scalars. A side effect of this change is that the array protocol won't be looked for on subclasses of Python scalars (int, long, float, complex). I don't expect that to be a problem. Some things we hadn't got around to: - integer arrays to a power (currently, these use pow()) - more optimization of integer powers enjoy the speed :-) -- |>|\/|< /--------------------------------------------------------------------------\ |David M. Cooke http://arbutus.physics.mcmaster.ca/dmc/ |cookedm(a)physics.mcmaster.ca

2 1

NumPy/Numeric/PyArray_Check
by Fred Clare 07 Mar '06

07 Mar '06

I have been a long-time Numeric user and have just started to use numpy-0.9.5 on a Mac running OS X Version 10.3.9. I installed NumPy in the same Python that has Numeric 24.2 installed. In using Numeric in my Python codes I have used only "import Numeric" for the import. After having installed "numpy" I replaced "import Numeric" with "import numpy as Numeric". All seems to go O.K. until I call a function in a module that uses Numeric (and not numpy) to create an array in my Python script. When I pass this Numeric array to a function in an extension module (that was compiled using the arrayobject.h from the NumPy distribution) and do a "PyArray_Check" on the Numeric array, it returns false. Is here a way around this? Based on the statement in the "Guide to NumPy" that Numeric and NumPy can be used simultaneously I was hoping that this would work. Fred Clare

1 0

numpy doc strings - a tool to list problem cases
by Colin J. Williams 07 Mar '06

07 Mar '06

Some of the docstrings have lines which are too long. Some names have no associated docstring. The effects of this are that, for the long lines, the PyDoc generated documentation is difficult to read on a browser and, for the missing cases, the generated docs are incomplete. The question of how long is too long is a matter of personal choice. I used 78 characters in the little script below that lists problem cases. # to check numpy docs, for long and missing lines import numpy lst= dir(numpy) lnMax= 78 # maximum number characters per line print 'Report of missing docstrings and docstrings with lines that are too long' print for nm in lst: txt= eval('numpy.' + nm + '.__doc__') if txt is None: print nm, 'No docstring' continue lns= txt.split('\n') for lnNo in range(len(lns)): ln= lns[lnNo] if len(ln) > lnMax: print nm, 'Line#:', lnNo, 'Line Length:', len(ln) z= 1 z= 1 Colin W.

1 0

numexpr
by Tim Hochberg 06 Mar '06

06 Mar '06

I just commited a bunch of changes to numexpr in the sandbox (BTW, thanks to Robert Kern for pointing me to the right location for that). At this point, there's a fairly complete framework for evaluationg numeric expressions (as long as they're not complex, and have unit stride and are all the same size etc, OK maybe not so complete, but potentially very useful nonetheless). A couple basic operations (** and %) need to be filled in as well as a bunch of functions. Still most basic operaions work. A bunch of 2- and 3-arg functions work as well as 'where'. I'll wait to hear from David Cooke to see how he likes the current function framework -- if he likes it, I'll go ahead and fill in the other common functions. It would also be nice to support sum and product as David mentioned, but I haven't though about that at all yet. At some point I'd like to add support for complex numbers as well, but I'd like to let the floating point stuff settle a bit first. -tim

2 1

Code cleanup patches
by Sasha 06 Mar '06

06 Mar '06

I would like to thank timl for the code cleanup patches. I've commited the ma.py patch to svn and the other patches seem to be acceptable as well. I assume you used some kind of automated code checking tool to spot the irregularities that you've fixed. It would be nice if you could describe your procedure and the tool that you used somewere on the developers' wiki. I've created a stub at http://projects.scipy.org/scipy/numpy/wiki/CodingStyleGuidelines . I assume that for the most part numpy can simply follow general python guidelines, but as more people start contributing code it maybe useful to document some guidelines.

2 1

Thoughts on an ndarray super-class
by Travis Oliphant 05 Mar '06

05 Mar '06

The bigndarray class is going to disappear (probably in the next release of NumPy). It was a stop-gap measure as the future of 64-bit fixes in Python was unclear. Python 2.5 will have removed the 64-bit limitations that led to the bigndarray and so it will be removed. I have been thinking, however, of replacing it with a super-class that does not define the dimensions or strides. In other words, the default array would be just a block of memory. The standard array would inherit from the default and add dimension and strides pointers. I was thinking that this might make it easier for sub-classes using fixed-sized dimensions and strides. I'm not sure if that would actually be useful, but since I was thinking about the disappearance of the bigndarray, I thought I would ask for comments. -Travis

4 4