Before anything, let me get certain concerns out of the way, right away
Mandatory disclosure: Just to prove that this is not some yet-another-LLM cracked-pottery, I did similar work for SciPy and hand-translated ARPACK, PROPACK, QUADPACK, ODEPACK and bunch of other packs (https://github.com/scipy/scipy/issues/18566 for the complete list, ~85K SLOC) when LLMs were not good for this type of work. Most of the translations are already released in previous SciPy versions so I hope that provides credibility for F77 -> C11 translation work. Now LLMs are slightly better and for LAPACK translation, I used Claude Code as an assistant for certain tasks. End of PSA.
-------- We now return to normal programming.
This is a C11 translation of the venerable Fortran77 linear algebra library, LAPACK. In case you can't afford or don't want Fortran dependency, this project might help. It works exclusively with a CBLAS interface to avoid the symbol naming bonanza that affects every other vendor (is it uppercase or not, with/out trailing underscore, ...). A bit controversially, translation is 0-indexed inside out, except the error codes. unfortunately `info = 0` encodes success so we can't do much about that.
Current test coverage; LAPACK own test suite (450K parametrized tests also mapped to C), NumPy test suite and SciPy test suite all pass. At least in the most common algorithms it is sound. For less covered ones, still there might be bugs and hence I marked it as alpha for now. But if you find any, write up an issue in the repo.
Also this makes it much easier to compile OpenBLAS and LAPACK with for your own machine or wherever it is meant to be running with architecture optimizations enabled and it works with a leaner binary size.
If you also want a drop-in replacement, there is also a fortran-shim supplied that will convert the wrappers to be seen as 1-indexed (that's how I tested NumPy/SciPy) with a bit of performance hit.
You can also name mangle the symbols to your liking with prefix and suffixes if you don't like the default. ILP64 is also supported and if you try to link with ILP64 CBLAS, it either complains if it was accidentally linked or handles things for you if you provide the flag.
The doxygen version of the documentation on Netlib, always rubbed me the wrong way for some reason; hence I tried my spin on it. It's here: https://ilayn.github.io/semicolon-lapack/
One particular detail I wanted to see often, was to see all four flavors at the same time; now they are grouped like this https://ilayn.github.io/semicolon-lapack/api/linear-systems/... If I failed please let me know, I'm still exploring the details. The default fonts, as an example, definitely need some love.
A couple of points as a futile attempt to prevent unhelpful discussions;
- There is nothing wrong with Fortran. If you like it keep using it. I don't, though big fan of Fortran77 for its era, not so much what is called the modern one.
- This work has nothing to do with Fortran. It tries to serve a particular audience that use exclusively a C toolchain and does not want inter-language issues.
- This work hopes to attract more people for optimizing the C code for common benefit.
Some more reasoning is given in the documentation.
Mandatory disclosure: Just to prove that this is not some yet-another-LLM cracked-pottery, I did similar work for SciPy and hand-translated ARPACK, PROPACK, QUADPACK, ODEPACK and bunch of other packs (https://github.com/scipy/scipy/issues/18566 for the complete list, ~85K SLOC) when LLMs were not good for this type of work. Most of the translations are already released in previous SciPy versions so I hope that provides credibility for F77 -> C11 translation work. Now LLMs are slightly better and for LAPACK translation, I used Claude Code as an assistant for certain tasks. End of PSA.
-------- We now return to normal programming.
This is a C11 translation of the venerable Fortran77 linear algebra library, LAPACK. In case you can't afford or don't want Fortran dependency, this project might help. It works exclusively with a CBLAS interface to avoid the symbol naming bonanza that affects every other vendor (is it uppercase or not, with/out trailing underscore, ...). A bit controversially, translation is 0-indexed inside out, except the error codes. unfortunately `info = 0` encodes success so we can't do much about that.
Current test coverage; LAPACK own test suite (450K parametrized tests also mapped to C), NumPy test suite and SciPy test suite all pass. At least in the most common algorithms it is sound. For less covered ones, still there might be bugs and hence I marked it as alpha for now. But if you find any, write up an issue in the repo.
Also this makes it much easier to compile OpenBLAS and LAPACK with for your own machine or wherever it is meant to be running with architecture optimizations enabled and it works with a leaner binary size.
If you also want a drop-in replacement, there is also a fortran-shim supplied that will convert the wrappers to be seen as 1-indexed (that's how I tested NumPy/SciPy) with a bit of performance hit.
You can also name mangle the symbols to your liking with prefix and suffixes if you don't like the default. ILP64 is also supported and if you try to link with ILP64 CBLAS, it either complains if it was accidentally linked or handles things for you if you provide the flag.
The doxygen version of the documentation on Netlib, always rubbed me the wrong way for some reason; hence I tried my spin on it. It's here: https://ilayn.github.io/semicolon-lapack/
One particular detail I wanted to see often, was to see all four flavors at the same time; now they are grouped like this https://ilayn.github.io/semicolon-lapack/api/linear-systems/... If I failed please let me know, I'm still exploring the details. The default fonts, as an example, definitely need some love.
A couple of points as a futile attempt to prevent unhelpful discussions;
- There is nothing wrong with Fortran. If you like it keep using it. I don't, though big fan of Fortran77 for its era, not so much what is called the modern one. - This work has nothing to do with Fortran. It tries to serve a particular audience that use exclusively a C toolchain and does not want inter-language issues. - This work hopes to attract more people for optimizing the C code for common benefit.
Some more reasoning is given in the documentation.
All feedback/criticism welcome.