[SciPy-user] Confusing BLAS/LAPACK situation on Mac OS X

Brian Granger bgranger at scu.edu
Sat Jan 28 17:47:39 CST 2006

Brian Granger, Ph.D.
Assistant Professor of Physics
Santa Clara University
bgranger at scu.edu
Phone: 408-551-1891
Fax: 408-554-6965
>>> oliphant.travis at ieee.org 01/28/06 3:23 PM >>>
Arnd Baecker wrote:

>With numpy
>  mat = zeros((Ny, Nx), fortran=1)
>should do the job (I have not tested this yet).
>If all the above is correct, then the solution I would use
>for myself is to set `fortran=1` for all arrays which
>will be used by some LAPACK routine.
>Then no unnecessary copies of (presumably large) arrays will take
>place on any machine and one could stop worrying about flapack
>vs. clapack ;-).
>Not sure if that is the solution for everyone - so I am happy
>to learn about any drawbacks....
This is the main purpose of the Fortran-order arrays in NumPy --- 
optimize interfaces to Fortran-written packages.   Right now, 
C-contiguous arrays still have a "special place" because several 
algorithms require C-contiguous arrays in order to work and will make 
copies of Fortran-order arrays as needed.  

There may still be some issues with these Fortran-order arrays 
especially regarding un-needed copying.  With Numeric, f2py did an 
intelligent job of deciding whether or not to copy.  Most of this is 
unneeded now because the FORTRAN flag on the NumPy array is kept 
up-to-date with the striding information on the NumPy array so that you 
just need to look at that flag to determine if the array is in 
Fortran-order or not. 


So it sounds like on Mac OS X, I should use fortran=1 in my numpy arrays if I will be calling things like linalg.eig.  That way no copies are made when they are passed to the Accelerate framework's versions of LAPACK which take column major arrays.

It is really nice to be able to pick the storage format like this.


SciPy-user mailing list
SciPy-user at scipy.net

This message scanned for viruses and SPAM at SCU (MGW2)

More information about the SciPy-user mailing list