[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
dtypechar...
>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.
-Travis
More information about the SciPy-user
mailing list