From version 1.19 of SciPy there will be no need for fortran compilers (because we translated everything to C https://github.com/scipy/scipy/issues/18566) and then all becomes much easier in all platforms due to the large availability of C compilers in all platforms. Together with the Stable API developments in CPython the wheel clash issues "hopefully" will decrease gradually.

This is a plausible assumption to make but unfortunately it is not true at large. Especially when the traditional sizes are exceeded say n >= 2000 certain operations such as LU can be improved in terms of performance with C-major arrays. However the correct statement is you lose at some place you win at other. There are certainly linalg operations that F-major can give you more performance. However it is also true for C-major layout.

In your example matrix vector product or any BLAS2 or BLAS3 level operations you can also swap out the for loop order to convert things around (row*col buffer multiplication vs sum of weighted column sum interpretation). In particular matrix norm operations are the only exceptions (abs column sum, row abs sum etc.) that certain norms prefer certain orders. In fact if you go into the Goto method deep enough you'll see that internal order is a bit like Morton ordering to fit things into L1 Cache.

The reason why column-major is preferred is historical and requires more surgery to get it running with C-major ordering. Trust me I tried but it's too much work to gain not so much. Maybe someday when I retire I can attempt it. Hence I kept it column major in my retranslation of LAPACK https://github.com/ilayn/semicolon-lapack

Instead I implemented a "high"-performance AVX2 matrix transpose operation so that swapping the memory layout is trivial compared to the linalg cost.

Another note to remember that John Backus, the team lead of the Fortran gang, was in the Algol committee. So these folks knew what they are talking about and spoke to each other periodically. Even John Backus said, Fortran is not the final interface that we should have.

It keeps spinning in the programming circles half-quoted versions of half-baked quotes from original sources. These pioneers, even when they disagreed, had pretty precise arguments and very rarely feeling the feelies.

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.

Comments URL: https://news.ycombinator.com/item?id=47644703

Points: 3

# Comments: 0

TimescaleDB is perfect if you also have relational data that you need to join with field data to the point that there no pros of using anything else for this use case, say you have 100000+ sensors and you need to group them by the customer site relations while aggregating per day statistics.

This does not mean Fortran is bad (obligatory disclaimer for Fortran fans).

I still remember their animations about car differential which were magical.

requiring n time the word Greek until you are satisfied is a you problem. I don't care enough about you to attack you personally. If you read more on these you would not get stuck in these accounting problems.

For those who are not related to the field, what the reported subject here (and destabilizing effect of the negative feedback) is fixed by Black to remedy amp ringing, led to Bell labs, develop frequency domain techniques later analyzed by Nyquist and Bode (also seniors in Bell labs) then made western control theory kick off (then united with the Soviet techniques) and today everybody losing their mind about boosters coming back to base with SpaceX (which was already done a few times historically decades ago).

- First make sure that the frequency is not dancing around. If it is then probably it is one of those things your brain making up then it is relatively easier to fool yourself back again. Check it when it happens https://audionotch.com/app/tune/ (disclaimer I am not related to website, just first google result).

- If it is constant then try to counter it with noise especially when trying to sleep. Just give yourself one of those nice YouTube colored-noise videos like this one https://www.youtube.com/watch?v=8SHf6wmX5MU

- Avoid in-ears altogether, especially the bass-boost ones make sure that it does not fit airtight. More bass does not mean you pulsate your ear-canal with an airgun. If you want proper bass sound, invest in hi-fi stereo and listen to it in a good room.

- As mentioned, distract yourself. Even if it is chronic and actually has a pathological cause, the brain finds a way to cope with it, like the glasses on your nose not noticing the weight.