RfC: Rewrite SLICOT in C
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 https://github.com/scipy/scipy/issues/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
gotopuzzles 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 https://github.com/scientific-python/faster-scientific-python-ideas/issues/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.
The code breakdown is as follows (using tokei tool)
SLICOT-Reference git:(main) tokei --sort code --exclude="examples/" --exclude="benchmark_data"
===============================================================================
Language Files Lines Code Comments Blanks
===============================================================================
HTML 587 179197 162832 4 16361
FORTRAN Legacy 623 291765 117072 174680 13
Makefile 3 239 132 87 20
Markdown 4 349 0 208 141
===============================================================================
Total 1217 471550 280036 174979 16535
===============================================================================
Do you mind taking a look at my repo SLICOT_C ? I have hard-forked SLICOT and written C wrappers that work on any platform.
It has full unit test coverage using gtest which include all documented examples. I tried to write the harold in Go but ended-up writing this wrapper and use Cgo :)
Nice work! But the annoying part is still the fortran dependence unfortunately.
I already wrote bunch of SLICOT routines in C just to try out. I'll push maybe this weekend the partial result.
Sure, I am interested.
@ilayn I just pushed a Rust translation too https://github.com/jamestjsp/slicot-rs
I added some structure and started pushing some routines now to SLICUTLET. It is not compilable as a library yet but I'll add more details this weekend (hopefully).