You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I am wondering if it would be useful to have a flag that indicates whether a complex tensor is conjugated or not.
This would make some operations a bit more complex, but since everything is a proxy anyway, I think it is achievable; eg if T has the is_conj flag set then T(0,1) = x; needs to be implemented as setting the memory at T(0,1) to conj(x). I can't see how that would be a problem for the Python interface.
But this would make some critical operations much faster, eg hermitian conjugate is simply permuting the indices and flipping the is_conj flag.
The big advantage is that it would make a lot of BLAS/LAPACK wrappers much easier. At the moment, in the BLAS/LAPACK wrappers, there is a lot of logic to explicitly transpose matrices (which shouldn't be needed anyway), and work-arounds for cases where the returned matrix would be the Hermitian conjugate of what is wanted. But if hermitian conjugation is a trivial operation of permuting indices and flipping a flag, then this problem goes away, and the wrapper functions can be simplified (quite dramatically, in some cases).
It should also be a performance improvement: probably a lot of the time where some function might leave a tensor in conjugated form, the next operation will be another conjugation. If not, then the conjugation will need to be performed anyway, but this is better than the current situation, where it is always performed, possibly twice in a row!
The text was updated successfully, but these errors were encountered:
The way it would work in the existing codebase is that if the conjugate flag is set, then _contiguous is set to false. This will cause the existing wrappers, that make the storage contiguous, to apply the conjugation operation and the existing wrappers should work as-is.
In time, the wrappers could be updated from requiring that the storage is contiguous, to requiring that it is blas_compatible(). It can then call blas/lapack functions with the appropriate leading dimension and transpose/hermitian parameter.
There will be some unknown other amount of code that does not require _contiguous, but would be incorrect if the is_conj flag is set. I am not sure how to identify such code. It can probably be done by forcing all access to go via a small set of conjugate-aware functions (eg Tensor::operator() and so on).
I am wondering if it would be useful to have a flag that indicates whether a complex tensor is conjugated or not.
This would make some operations a bit more complex, but since everything is a proxy anyway, I think it is achievable; eg if T has the
is_conj
flag set thenT(0,1) = x;
needs to be implemented as setting the memory atT(0,1)
toconj(x)
. I can't see how that would be a problem for the Python interface.But this would make some critical operations much faster, eg hermitian conjugate is simply permuting the indices and flipping the
is_conj
flag.The big advantage is that it would make a lot of BLAS/LAPACK wrappers much easier. At the moment, in the BLAS/LAPACK wrappers, there is a lot of logic to explicitly transpose matrices (which shouldn't be needed anyway), and work-arounds for cases where the returned matrix would be the Hermitian conjugate of what is wanted. But if hermitian conjugation is a trivial operation of permuting indices and flipping a flag, then this problem goes away, and the wrapper functions can be simplified (quite dramatically, in some cases).
It should also be a performance improvement: probably a lot of the time where some function might leave a tensor in conjugated form, the next operation will be another conjugation. If not, then the conjugation will need to be performed anyway, but this is better than the current situation, where it is always performed, possibly twice in a row!
The text was updated successfully, but these errors were encountered: