Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Implicit complex conjugation? #519

Open
ianmccul opened this issue Nov 24, 2024 · 1 comment
Open

Implicit complex conjugation? #519

ianmccul opened this issue Nov 24, 2024 · 1 comment
Assignees
Labels
enhancement New feature or request

Comments

@ianmccul
Copy link
Contributor

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!

@ianmccul
Copy link
Contributor Author

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).

@yingjerkao yingjerkao self-assigned this Nov 29, 2024
@yingjerkao yingjerkao added the enhancement New feature or request label Nov 29, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants