-
Notifications
You must be signed in to change notification settings - Fork 45
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
Incorrect type of Real irrep as Complex irrep in C(n)
and SO(2)
#49
Comments
Hi @Danfoa Thanks for the question! Sorry for the confusion, but our library supports only real representations (so no complex valued irreps). These are all real irreps and, depending on the class, they decompose into complex irreps in different ways. An important property is that complex-type irreps are essentially equivalent to the "realification" of a complex irrep (e.g. the 2D rotaiton matrix is the realification of the 1-dim complex number), which allows you to "simulate" complex irreps by using real ones. You can find more details about this in the appendix C of our paper. Hope this helps! Gabriele |
Hi @Gabri95 I understand now. Do you think there is value in placing efforts into introducing support for complex representations? Considering that: (1) representation theory is simpler and commonly given over the complex field. (2) Some applications are more convenient with complex reps, (3) I bet a lot of people would be happy to have support for Complex irreps.
I would assume this would be done by defining the appropriate mappings between complex and real irreducibles and exploiting all the machinery you have already built. To motivate my argument, and probably get some guidance from your side. Consider that my biggest limitation in the use of the Representation class has been that in order to create an instance of a representation I need to know in advance the change of basis and the list of real-irreducibles. In practice what I have are:
To solve this I have code for the Isotypic Decomposition of the "known" representations into their complex irreducibles. And I am now, trying to produce the matching between the group known real irreps, provided by ESCNN, and the empirical complex irreps, found through the Isotypic Decomposition. To my surprise, the mapping between complex and real irreps has been more challenging to solve than the actual Isotypic Decomposition, but once I solve this. I will be able to instanciate |
Hi @Danfoa Thanks for bringing this up. I understand the need for an interface for the user to construct real representations from complex ones, but I am not convinced yet the library should support complex representations. The key observation is that any complex representation must be implemented via its realification (i.e. storing the real and imaginary components as a 2-dimensional real number). Hence, I fear directly supporting complex irreps will lead users to mistakenly build suboptimal models. Still, I agree this conversion process should be more automated. In this way, the user would still use only real representations but could create them more easily starting from complex ones. Best, |
I don't know if it would be outside the scope of the library, but I'm interested in the Unitary group U(n), which (I think) would require a complex representation. |
In the function
Group.irrep
of bothC(n)
andSO(2)
the convention of real Irreducible representations is used. However ever there is a mislabeling of the type of irreps as complex, which will create issues for applications where the distinction of real and complex irrep is necessary.More precisely, irreducibles associated to rotations on the plane not aligned any coordinate axis, are constructed in:
escnn/escnn/group/groups/cyclicgroup.py
Lines 436 to 445 in b101341
escnn/escnn/group/groups/so2group.py
Lines 456 to 461 in b101341
As can be clearly seen from the comments and from the method
group.utils.psi
used to build the 2-dimensional representations:escnn/escnn/group/utils.py
Lines 6 to 15 in b101341
These representations are Real rotation matrix representations. As it is known, any 2D rotation matrix is decomposable into two 1-dimensional Complex irreducible representations.
This brings several problems all emerging from the fact that you are labeling a complex representation as irreducible, when in fact it is decomposable. Beyond the trivial solution to the issue of changing the type of these irreps to Real, this issue points to a potential source of error in ESCNN by not having a method for actually checking if an irrep is in fact an irrep.
At least for complex irreducibles, this can be easily checked with:
Let me know if this sounds like a good possible PR. I will contribute it gladly.
The text was updated successfully, but these errors were encountered: