I would use a complex32 dtype if it existed, whether provided by numpy or
another library.
My guess would be that there was not much demand for a complex32 datatype
since float16s are slow and are generally used as a storage format [1] and
you could easily store a complex array as two float16 arra
A previous discussion of adding a .H operator on the mailing list can be
found here:
http://numpy-discussion.10968.n7.nabble.com/add-H-attribute-td34474.html
that thread refers to an earlier discussion at
http://thread.gmane.org/gmane.comp.python.numeric.general/6637
but that link was broken for me
of matrices, vectors and scalars. Elementwise conjugation is well
>>>> inline with other elementwise operations starting with a dot in matlab
>>>> hence still consistent.
>>>>
>>>> I would still expect an conjugation+transposition to be the defau
I would love for there to be .H property. I have .conj().T in almost every
math function that I write so that it will be general enough for complex
numbers.
Besides being less readable, what puts me in a bind is trying to
accommodate LinearOperator/LinearMap like duck type objects in place of
matr
