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

Quaternionic unitary group #506

Merged
merged 11 commits into from
Jul 22, 2022
Merged

Quaternionic unitary group #506

merged 11 commits into from
Jul 22, 2022

Conversation

mateuszbaran
Copy link
Member

This should solve #382 . exp and log are currently only supported for the n=1 case because I couldn't find a generic quaternionic matrix exponential and logarithm.

Also, plain numbers should also work for QuaternionicUnitary(1).

@mateuszbaran mateuszbaran marked this pull request as ready for review July 21, 2022 15:05
@mateuszbaran mateuszbaran added the preview docs Add this label if you want to see a PR-preview of the documentation label Jul 21, 2022
@sethaxen
Copy link
Member

exp and log are currently only supported for the n=1 case because I couldn't find a generic quaternionic matrix exponential and logarithm.

They can be supported by expanding each quaternion into its 2x2 complex matrix representation, which become blocks in a matrix with nxn blocks, so an nxn quaternionic matrix corresponds to an 2nx2n complex matrix. This transform preserves the matrix product, so the result is a closed subgroup of U(2n), on which one can compute exp/log and then map back to quaternions.

But I think it's best to handle this kind of thing at the level of the quaternion implementation, not here. e.g. Quaternions.jl had JuliaGeometry/Quaternions.jl#46 for adding support for matrix exponential, and this could be expanded to support all matrix functions. Are there fallbacks to for exp_lie and log_lie that call the matrix exponential? If so, then this would already be supported with such a PR to Quaternions.

Why QuaternionicUnitary(n) and not something like Unitary(n, 𝔽=ℂ)? That would be more consistent with how we allow constructors to take fields elsewhere.

@codecov
Copy link

codecov bot commented Jul 21, 2022

Codecov Report

Merging #506 (fa488a5) into master (0cd7158) will increase coverage by 0.00%.
The diff coverage is 100.00%.

@@           Coverage Diff           @@
##           master     #506   +/-   ##
=======================================
  Coverage   98.87%   98.87%           
=======================================
  Files          96       96           
  Lines        8714     8735   +21     
=======================================
+ Hits         8616     8637   +21     
  Misses         98       98           
Impacted Files Coverage Δ
src/Manifolds.jl 100.00% <ø> (ø)
src/groups/unitary.jl 100.00% <100.00%> (ø)
src/manifolds/GeneralUnitaryMatrices.jl 100.00% <100.00%> (ø)
src/manifolds/Unitary.jl 100.00% <100.00%> (ø)

📣 Codecov can now indicate which changes are the most critical in Pull Requests. Learn more

@mateuszbaran
Copy link
Member Author

They can be supported by expanding each quaternion into its 2x2 complex matrix representation, which become blocks in a matrix with nxn blocks, so an nxn quaternionic matrix corresponds to an 2nx2n complex matrix. This transform preserves the matrix product, so the result is a closed subgroup of U(2n), on which one can compute exp/log and then map back to quaternions.

Thanks, I didn't know that.

But I think it's best to handle this kind of thing at the level of the quaternion implementation, not here. e.g. Quaternions.jl had JuliaGeometry/Quaternions.jl#46 for adding support for matrix exponential, and this could be expanded to support all matrix functions. Are there fallbacks to for exp_lie and log_lie that call the matrix exponential? If so, then this would already be supported with such a PR to Quaternions.

OK, so I won't work on that here in this PR. Currently there are no such fallbacks but they will be easy to add when quaternionic matrix exp is available.

Why QuaternionicUnitary(n) and not something like Unitary(n, 𝔽=ℂ)? That would be more consistent with how we allow constructors to take fields elsewhere.

Mostly to be consistent with the existing Orthogonal/Unitary. I don't have a strong opinion about it but maybe let's ask @kellertuer what he prefers.

@kellertuer
Copy link
Member

Why QuaternionicUnitary(n) and not something like Unitary(n, 𝔽=ℂ)? That would be more consistent with how we allow constructors to take fields elsewhere.

Mostly to be consistent with the existing Orthogonal/Unitary. I don't have a strong opinion about it but maybe let's ask @kellertuer what he prefers.

I think for Orthogonal and Unitary there is different terms and names, so that's why I preferred to split that, but for complex or quaternionic Unitary the field should be fine.

@mateuszbaran mateuszbaran added the Ready-for-Review A label for pull requests that are feature-ready label Jul 22, 2022
@mateuszbaran mateuszbaran merged commit 595195f into master Jul 22, 2022
@kellertuer kellertuer deleted the mbaran/quaterninic-unitary branch May 4, 2024 17:33
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
preview docs Add this label if you want to see a PR-preview of the documentation Ready-for-Review A label for pull requests that are feature-ready
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants