Incorrect type of Real irrep as Complex irrep in `C(n)` and `SO(2)` about escnn HOT 4 OPEN

Hi @Danfoa

Thanks for the question!

Sorry for the confusion, but our library supports only real representations (so no complex valued irreps).
The label "R" or "C" does not refer to the field over which the representations are defined, but the "type" of the real irrep.
Indeed, real irreps of any compact group belong to one of three classes: real type, complex type or quaternionic type.

These are all real irreps and, depending on the class, they decompose into complex irreps in different ways.
For example, a complex-type irrep decomposes into two complex irreps, like in your SO(2) example, while real-type irreps do not decompose further into complex irreps.

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

from escnn.

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.

• For instance, I am working with linear symmetrical dynamical systems, where I am required to do Isotypic Decomposition of a representation into its complex irreps, facilitating mode-decomposition, plotting of complex observations, and a general understanding of the dynamics. I expect this to have applications in both ML and dynamical systems theory.

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:

1. Somewhat large vector spaces.
2. Knowledge of the symmetry group that the space has.
3. Knowledge of the symmetry representations in that space for all group elements. These representations are not trivial combinations of real-irreps or of the regular rep. Therefore is not trivial to determine both Q and the real irrep list.

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 Representations solely by providing the callable/mapping of group elements with matrices.

from escnn.

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).
However, the realification of a complex irrep is either a real irrep or decomposes into real irreps; moreover, real irreps can have larger intertwiner spaces (i.e. they support more equivariant linear maps), with direct implications on the expressivity of an equivariant network, as we discussed in our first paper for SO(2).
Let me refer you again to the appendix C of our paper for more technical details.

Hence, I fear directly supporting complex irreps will lead users to mistakenly build suboptimal models.
Forcing the users to convert their complex representations into real representations should make them aware of this situation.

Still, I agree this conversion process should be more automated.
The best idea that comes to my mind now is leveraging the
decompose_representation_general method (which takes any representation implemented as a function Group -> Matrix and numerically decomposes it using the group's irreps).
This could be wrapped into a decompose_complex_representation method which 1) computes the realification of your complex representation and 2) uses decompose_representation_general to decompose it.

In this way, the user would still use only real representations but could create them more easily starting from complex ones.
Do you think this could solve your issue?

Best,
Gabriele

from escnn.

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.

from escnn.