[SciPy-user] Inverting Complex64 array fails on OS X
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