[SciPy-User] Q: Provide .H for numpy arrays?
Dag Sverre Seljebotn
Thu Oct 14 12:05:28 CDT 2010
On 10/14/2010 04:30 PM, Nico Schlömer wrote:
>> In any case, I think that you need to raise this issue on the list for discussion.
> Now here's what for discussion:
> I noticed that one difference between numpy arrays and matrices is
> that ".H" (transpose + conjugation) is only implemented for matrices.
> ".T", however, being structurally completely equivalent, is
> implemented for both.
> While an actual use case for ".H" would be mass dot-products for
> multivectors. Right now, I guess what most people go with is
> ".T.conjugate()" where it's needed.
> Something that may play a role here is the fact that .vdot() does --
> as opposed to .dot() -- not allow for dot-products with multivectors.
Does this belong on the numpy-discuss list?
I think the proposal needs further details. ".T" is NOT completely
equivalent because no copying takes place. Modifying "arr.T" modifies
"arr" as well, while the ".H" of the matrix class makes a copy of the data.
There is an alternative. Each array view could have a flag saying
whether it is conjugated or not, and then "arr.H" would return a
"conjugated view". This would be much more useful. Any routines actually
accessing the data (item assignment, storing to disk, ufuncs...) would
have special cases added to do the conjugation in the operations instead
of having to copy the data.
This would play very nice with constructs such as np.dot(arr.H, arr),
because the underlying BLAS can take flag to conjugate the data (which
to my knowledge is not available from NumPy currently).
Of course, it is likely a lot of work. But the existance of the
possibility of this path in the long run makes me negative towards the
proposal of just implementing "arr.H" the easy way (making a copy) in
the short run because it would make it impossible to introduce something
much more useful later on. A naive implementation of "arr.H" would not
work well with gigabyte-sized arrays on most computers, and is always
available as "arr.T.conjugate()" anyway, which is more explicit about
making a copy.
Just my cents,
More information about the SciPy-User