Alternative name for the new C translation of ARPACK

Hi everyone,

As you might have seen, we have completed the C translation of ARPACK for SciPy and cleaned up the obvious bugs (there might still be a few left in the complex version, feedback is highly appreciated if you encounter anything) ENH:MAINT: sparse.linalg: rewrite ARPACK in C by ilayn · Pull Request #22748 · scipy/scipy · GitHub

The translation touched a few things. The most obvious one is that the randomization parts are taken out from ARPACK internals and now can be seeded externally say via a NumPy rng. Similarly the reverse communication layer is now uses a Python dict ↔ C struct for inter-communication and not passing a gazillion single variables. All this means that the API compatibility is broken.

Hence, we decided to rename the implementation to avoid confusion with potential external users. Any good names that you can think of? The relevant keywords are Arnoldi Method, Implicitly Started Arnoldi Method (IRAM), large scale eigenvalue solver…

  • ARPAX
  • ARPACKX
  • IRAMinC
  • etc.

Naming things is very difficult and annoying hence this request for help.

If there are no objections, CARPARK is a distinct enough name that won’t show up in any ?arpack? queries and does not clash with any other ARPACK clones out there in many languages; ARPACKPP, ARPACK++, ezARPACK, ARPACK.jl, ARPACK-eigen, GenericArpack.jl, ARPACK-ARMA etc.

Not that anybody would care about this obscure code but just in case.

I feel we could lean into using “sp” for “scientific python” more consistently, continuing from recent examples (e.g. spin, the discourse, etc.). So, my first thought would be something like

  • SPARPACK
  • SP-ARPACK
  • ARPACK-SP

While CARPARK is a catchy name, I feel we’d be the c-c-c-combo breaker here; all the other ARPACK clones you mentioned kept the “ARPACK” substring, so going from paCk to paRk will make our implementation the most special one – not sure if that’s justified or desirable.

True and I am hoping to break that combo because we are breaking API and diverging from ARPACK family. Pretty much what Spectra or ArnoldiMethods.jl did (they are also ARPACK “clones” but with different APIs).

The main reason is to steer away from the name ARPACK to avoid confusions.