[SciPy-User] Q: Provide .H for numpy arrays?

Dag Sverre Seljebotn dagss@student.matnat.uio...
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.
>>      
> Raise!
>
> 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,

Dag Sverre


More information about the SciPy-User mailing list