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

[Nico Schlömer]

> I think the proposal needs further details. ".T" is NOT completely
> equivalent because no copying takes place.

That's right, I was more thinking about semantic, mathematical equivalence.
Looking at the code, this is certainly a different matter about which
I, as a Scipy user, don't know much.

As mentioned in the previous mail, at this moment there appears to be
no possibility to efficiently block-dot-product two complex-valued
blockvectors as vdot() doesn't work for blocks, and

    np.dot( z.T.conjugate(), z )

unnecessarily creates and intermediate vector. Correct?
The suggested view option would certainly help out here.

Cheers,
Nico



On Thu, Oct 14, 2010 at 7:05 PM, Dag Sverre Seljebotn
<dagss at student.matnat.uio.no> 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).
>
> 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
>