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

[Dag Sverre Seljebotn]

On 10/14/2010 07:05 PM, Dag Sverre Seljebotn wrote:
> 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).
>    

Correction: It's available in vdot.

Dag Sverre

> 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
> _______________________________________________
> SciPy-User mailing list
> SciPy-User at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-user
>