From my web statistics it looks like about 100 people downloaded it. Should give Numpy a pretty good showing as I got it running almost as fast as C. Only slowdown was dumping the E fields into a file every few ticks to generate the movie. I know there must be better ways to dump an array than use indexing- but I was so excited when I finally got it to near C speeds that I just let it be. Rob. -- The Numeric Python EM Project
www.members.home.net/europax
Rob wrote:
Only slowdown was dumping the E fields into a file every few ticks to generate the movie. I know there must be better ways to dump an array than use indexing-
If you want to dump the binary data, you can use: file.write(array.tostring) If you need an ASCI representation, you can use various forms of: format_string = '%f '* A.shape[1] + '\n' for r in range(A.shape[0]): file.write(format_string%(tuple(A[r,:]))) You could probably use map to speed it up a little as well. I'd love to see an array-oreinted version of fscanf and fprintf to make this faster and easier, but I have yet to get around to writing one. -Chris -- Christopher Barker, Ph.D. ChrisHBarker@home.net --- --- --- http://members.home.net/barkerlohmann ---@@ -----@@ -----@@ ------@@@ ------@@@ ------@@@ Oil Spill Modeling ------ @ ------ @ ------ @ Water Resources Engineering ------- --------- -------- Coastal and Fluvial Hydrodynamics -------------------------------------- ------------------------------------------------------------------------
Rob wrote:
Only slowdown was dumping the E fields into a file every few ticks to generate the movie. I know there must be better ways to dump an array than use indexing-
If you want to dump the binary data, you can use:
file.write(array.tostring)
If you need an ASCI representation, you can use various forms of:
format_string = '%f '* A.shape[1] + '\n' for r in range(A.shape[0]): file.write(format_string%(tuple(A[r,:])))
You could probably use map to speed it up a little as well.
I'd love to see an array-oreinted version of fscanf and fprintf to make this faster and easier, but I have yet to get around to writing one.
Check out the IO secion of SciPy. Numpyio along with a flexible ASCII_file reader are there. -Travis
In migrating from python 1.5.2 and Numeric 13 to python2.1.1 with Numeric-20.1.0 I have encountered a rather pernicious problem. I had previously been using f2py 1.232 to generate modules for the BLAS and a self-consistent subset of LAPACK. Importing the thus created blas and then lapack modules made their FORTRAN routines available to the FORTRAN code that I had written. Everything worked well. However, after I compiled python2.1.1 and Numeric-20.1.0 importing the blas and lapack modules no longer provides access to their routines. Moreover, I can't even import the lapack module because it requires routines from the blas module (that it can no longer see). I get this behavior on both RedHat 7.1 and 6.1 (e.g. with and without gcc 2.96). I verified that python2.2a behaves as 2.1.1 in this regard as well. I tried linking generating blas and lapack libraries and linking them during creation of the shared libraries but that only worked marginally. I am still geting unresolved symbol errors. Has anyone else seen this problem/difference? -Todd
FORTRAN code that I had written. Everything worked well. However, after I compiled python2.1.1 and Numeric-20.1.0 importing the blas and lapack modules no longer provides access to their routines. Moreover,
Were you relying on symbols from one dynamic module being available to other dynamic modules? That was never guaranteed in Python, whether or not it works depends on the platform but also on the Python interpreter version. I am not aware of any relevant changes in Python 2.1, but then none of my code relies on this. The only safe way to call C/Fortran code in one dynamic module from another dynamic module is passing the addresses in CObject objects. Konrad. -- ------------------------------------------------------------------------------- Konrad Hinsen | E-Mail: hinsen@cnrs-orleans.fr Centre de Biophysique Moleculaire (CNRS) | Tel.: +33-2.38.25.56.24 Rue Charles Sadron | Fax: +33-2.38.63.15.17 45071 Orleans Cedex 2 | Deutsch/Esperanto/English/ France | Nederlands/Francais -------------------------------------------------------------------------------
participants (5)
-
Chris Barker -
Konrad Hinsen -
Rob -
Todd Alan Pitts, Ph.D. -
Travis Oliphant