Rob wrote:
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 -------------------------------------- ------------------------------------------------------------------------
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
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 -------------------------------------------------------------------------------
Rob wrote:
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 -------------------------------------- ------------------------------------------------------------------------
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
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