[SciPy-user] Inverting Complex64 array fails on OS X

Andre Radke lists at spicynoodles.net
Sun Jan 15 15:53:56 CST 2006

Robert Kern wrote:
>Accelerate.framework only contains the FORTRAN version of LAPACK, yes. I do
>believe it contains CBLAS (given the existence of cblas_* symbols in 
>the dylib), though.

Okay, thanks. In the meantime, I think I have figured out why 
inverting a matrix of type Complex64 failed for me:

The implementation of linalg.inv() in scipy/linalg/basic.py uses 
get_lapack_funcs() in scipy/lib/lapack/__init__.py to obtain the 
reference to the underlying Fortran functions for performing the 
matrix inversion. get_lapack_funcs() examines the dtypechar attribute 
of the provided matrix to determine whether to use the single/double 
precision and real/complex version of the Fortran functions.

The dtypechar attribute of my Complex64 matrix was 'G'. This wasn't 
one of the type code chars expected by get_lapack_funcs(), so it 
defaulted to the version of the Fortran functions that take double 
precision real arguments, i.e. dgetrf and dgetri. Consequently, 
linalg.inv() returned only the inverse of input's matrix real part.

I suspect my Complex64 matrix would instead have required using the 
zgetrf and zgetri Fortran functions (for a double precision complex 
argument) which would have happened if the dtypechar of the matrix 
had been 'D' instead of 'G'.

Is this actually a bug in get_lapack_funcs() or are my assumptions 
about how this should work simply incorrect?

Also, is Complex64 the preferred way to specify a double precision 
complex dtype when constructing a matrix?



Andre Radke + mailto:lists at spicynoodles.net + http://www.spicynoodles.net/

More information about the SciPy-user mailing list