As folks following SciPy by now might know, as a member of SciPy core maintainer team, I embarked on a (in hindsight very frustrating and time-wasting) journey of translating all Fortran code to C/Cython/Python that is coming to a finish (progress is here scipy/scipy#18566)

The main reasons for that were, very frustrating distribution effort across (different architectures) X (compilers) X (Python versions), code that is almost impossible to maintain or debug, and many others.

While that is slowly coming to fruition, it seems like I did not learned my lesson and put my eyes on SLICOT as it is also very annoying to compile and distribute. SLYCOT, which served a wonderful purpose until now, unfortunately started its journey as GPL and makes the licensing situation very difficult.

One upshot for SLICOT compared to SciPy Fortran code is that I know a lot about what SLICOT does internally (unlike what MINPACK or ODEPACK did). So I can reason about the code when it comes to balancing realizations and other boring control stuff. Moreover SLICOT has a lot of great stuff in it that is not available conveniently elsewhere unless you have matlab license. So it is quite important that this knowledge is available to everyone. Thankfully, SLICOT authors relicensed the code to BSD-3 (from GPL-v3) since version 5.0 which is very generous of them such that we can look at the code now.

As I spent most of my time on SciPy in the last years, harold also received no love from me and bits and pieces are subsumed into python-control (which is great news). However there is an obvious hurdle in the open source community for fast performing control code. While many parts of harold is designed for convenience and updated literature they are still coded in Python.

Anyways, are there any volunteers who wants to collaborate on this?

The vacancy requirements are

• They know a bit of C/Cython (which is really not much)
• They know some control theory (which is also not much, I can help with the control issues)
• They know a bit of column vs row major and other very annoying Fortran vs C differences (again I can help).
• They do not mind decrypting goto puzzles from 5 to 7 decades ago in an obscure language
• They are not good at making good life decisions (given the task at hand)

I know not many folks visit this repo anymore but good to record the query for help somewhere. I'll start slowly in somewhere 2026 anyways.

Thank you for sparing time for my diatribe.

For avoiding pointless "why not C++ instead of C discussions", you do you, I would run towards a wall of nails instead of debugging C++ errors for days ever again.

Or alternatively, please refer to scientific-python/faster-scientific-python-ideas#7 and please note that I tried it many times before so this is coming from actual F77 translation experience and not some 5 minute guesswork.