[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [pygame] Numpy slower than Numeric

Brian Fisher wrote:
On 12/28/06, Lenard Lindstrom <len-l@xxxxxxxxx> wrote: 
Well, pygame compiles with numpy, but not everything works right. So it
is not a simple switch.

What kind of problems are there? is it like crashing? bad (incorrect)
behavior? deprecated numeric functionality that needs a new way to do
things with numpy? or is it that existing python code written to use
the numeric interface of pygame would need to be changed to work with
numpy?

When you say it compiles, do you mean with the numeric compatibility
interface stuff (numpy/oldnumeric.h) or do you mean when stuff is
changed to use numpy without that file? also, is there any prior work
for porting to use numpy that would be good for somebody to build off
of? (i.e. like a pygame branch or patch, or maybe unit tests that show
how things fail when compiled with numpy?)

I compiled pygame 1.8.0rc1 surfarray and sndarray with numpy/oldnumeric.h for Python 2.5 using mingw. I placed the dlls with a pygame 1.8 mingw build. Both modules compiled cleanly. Nothing crashed using surfarray. The biggest difference was pixels_alpha returning a read-only array. Also the "striped" and "scaleup" parts of the arraydemo.py pygame example, modified to use numpy, created all-black images. There were small changes needed in the python code to make things run, replacing UInt8 with uint8 for example. That was about all the testing I did. I did not try sndarray.

The scipy site gives little information on porting at the C level. No C api documentation is freely available.

--
Lenard Lindstrom
<len-l@xxxxxxxxx>