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

Travis Oliphant oliphant.travis at ieee.org
Sun Jan 15 17:05:05 CST 2006

Andre Radke wrote:

>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 is definitely the problem.  It should be 'D'.  'G' is a complex 
number with long doubles.

How did you specify the matrix again?   Could you show us some of the 
attributes of the matrix you created.  I'm shocked that 'G' was the 

>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?
No.  Use numpy.complex128  or 'D' or just simply complex.


More information about the SciPy-user mailing list