Thanks for your interest and kind words!

Indeed, the class is named SphereIcosahedral. It has been renamed in epfl-lts2/pygsp@d8c4a28 to have a more uniform naming. Could you try to rename SphereIcosahedron to SphereIcosahedral? If that works, I'd be happy to merge a PR. :)

Could you try to rename SphereIcosahedron to SphereIcosahedral? If that works, I'd be happy to merge a PR. :)

OK, got it. The parameter signature of the constructor has changed though. I'm assuming the new subdivisions argument can be calculated as 2ⁿ where n is the order of the Icosahedron?

There are a few other minor updates required that I'll add to a PR.

The parameter signature of the constructor has changed though.

Right. That was done in epfl-lts2/pygsp@39a0665 to unify the parameters across the multiple discretizations of the sphere.

I'm assuming the new subdivisions argument can be calculated as 2ⁿ where n is the order of the Icosahedron?

Correct. While subdivisions must be a power of 2 in the current implementation, the API change allows for a more general implementation in the future if needed.

We did actually update the required PyGSP version to fix a bunch of issues (#7). But those API changes got overlooked.

Looking forward to the PR. Many thanks @phil-hawkins!

The project runs now, however it seems like the performance isn't where it should be, at least with the default config with respect to the results in the paper. I'm not sure if this related to the config, my changes or something earlier.

This is the result form the final epoch run with default config:
Starting Epoch: 30
beginning validation epoch
Average precisions: [0.99981521 0.29534943 0.87257515]
mAP: 0.5839622866476017

Do you have any ideas on this @mdeff?