Unable to instantiate `R3IcoConv` about escnn

[Gabri95]

Hi @kalekundert

Thanks a lot for spotting this issue! I introduced a small bug recently which indeed broke the steerable bases used to construct R3IcoConv. This is fixed now!

Regarding the question:

Would you ever recommend using R3Conv instead of R3IcoConv with the icoOnR3 gspace?

I would generally recommend using R3Conv always. The R3IcoConv is using an unstable steerable basis (it often doesn't pass the equivariance tests) and it was implemented to demonstrate the benefits of the harmonic bases used in R3Conv (see Figure 5 in our paper).

I am realising now that this is not emphasised in the documentation. I'm sorry for the confusion, I'll add a warning about this!

I know that in the 2D case, you can do group convolutions that are C(n)-equivariant with standard, unconstrained kernels by "lifting" the input to a higher dimension. Can R3IcoConv be thought of as a 3D version of this?

Yes, that's correct, as long as you use an output regular representation.

If so, I'd expect that it wouldn't be necessary to calculate irreps. I suspect that this analogy is just wrong, but I'm not sure.
Are these irreps actually used by R3IcoConv?

This library implements general steerable CNNs, of which group convolution is just a special case given by the choice of the regular representation.
Moreover, unless one considers only the discrete group of symmetries of the grid (e.g. C_4 or the octahedral group), lifting unconstrained kernels still requires express them in terms of a steerable basis (as done for C_N equivariance in this paper). Working with a steerable basis implicitly implies working with the group's irreps.

For these reasons, we still need the irreps of the Icosahedral group to implement a GCNN equivariant to this group.

I notice that it takes ≈20s to build the icosahedral irreps when instantiating the icoOnR3 gspace

This should have been fixed thanks to your pull-request ;)

Hope this helps and sorry for the delay in my answer!
Gabriele