ilayn

Not really, all competitive compilers saturated to the same performance. Often Fortran and "restrict" sprinkled C compile to the same command set.

Not to take away from your points; SciPy is now Fortran-free completely[0] (we are also requiring C++17 at most). NumPy never had it. BLAS is all C/Assembly in all optimized vendors. For LAPACK we are working on it [1].

Once there is enough pain, none of the talking points matter for any language. They don't and can't die but linger. I fear that time for C family might come in a decade which would be a shame given how magical Cpp compilers are, all that effort folks pouring in.

[0]: https://github.com/scipy/scipy/issues/18566 [1]: https://github.com/ilayn/semicolon-lapack

ahem... https://github.com/ilayn/semicolon-lapack

It is mostly out of habit. These days there are no differences between languages. Very often they compile to the same machine code. Fortran array syntax is light years ahead of what C++ offers (yes including std::linalg and that's why numpy, julia, matlab picked it up) but lacks everything else as a language including often claimed portability.

Ah, my bad. what I failed to emphasize is that many of the downstream issues are coming from the upstream restrictions so this is one of the major blocks that was causing some mayhem down the line. So indirectly we might have caused some heartburn for you, apologies in advance.

Scipy maintainer here, the main issue with the wheels was the Fortran77 that was SciPy throwing wrenches into the mix. With C/C++ self compilation should be quite straightforward. We (all Scientific Python packages) really worked hard on that.

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.

It does not have to be in Fortran. It's just historical reason. If you want a C version of LAPACK I have one for you https://github.com/ilayn/semicolon-lapack

> Actually the column-major order of Fortran is more efficient for some linear algebra operations than the order of C, which has been inherited by many modern languages that do not care about high performance in scientific computations.

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.

Read the sources carefully. Fortran quote is not his; he quoted it. Also remember that he was talking about pre-Fortran77 era. F77 tried to fix some of the criticisms though did not succeed fully. Here is a nice dig-in about the quote https://limited.systems/articles/dijkstra-fortran/

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.

Wow what's next, scrolling title text? What a time to be alive...

Similar to your mqtt converter you can make them ingest via Kafka or some other adapter in between. EMQX broker can directly write into TSDB but did not research into others whether they can or not.

Not the OTEL "telemetry" but sensors sending measurements from the field "telemetry". IT tech is, as usual, stealing perfectly defined engineering words and making them something else.

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.

I'm working in the IIoT domain too. Your workflow is interesting towards the end. Any particular reason, why you don't write it to some db like Timescale or Influx at the end without any prometheus conversion?

NumPy has no Fortran code, for quite a long time now. SciPy has and it is being rewritten. What you mention is the ufunc machinery underneath which is all C. NumPy also has SIMD support (albeit limited to certain functions). BLAS is also C/Assembly but only LAPACK is F77 (which is too much code to be rewritten).

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

(Laughs in control theory)

Which is an integral part of the public discourse.

Same experience for me. I was able to buy my first drumset from the money I got for making a PHP+MySQL+HTML website for someone (also done all in notepad). I did not know anything about computers but I needed to buy a drumset. And that page actually got me going about how HTML works.

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

You should read more carefully to start with before accusing everything you see that does not fit into your narrative.

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.

Anatolia is a Greek word. Read some. It will give you confidence about yourself so you don't seek confirmation from every piece.

This is a bit of a strange presentation of stability but I liked it. I don't agree with the phase margin absence in the other comment but it would have been much clearer if the author chose to present it once via a Nyquist plot, then stuck with the magnitude plots which would clarify what we are talking about. It is also very welcome clarity to see that we are not using the weird dB unit in Bode plots.

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).

I think you are also giving yourself too much credit on the separability of tense and mood and if it does not fit into your mental model you are discarding all other options. You can do the same research yourself. Mood and tense are not always separable as you might think. Morphology is a red herring here. It clearly transmits the essential time information and also adds mood no-confirm structure on top. Hence if you don't consider that as a tense, then I have the same suspicion about your knowledge and obviously I might be also wrong.

You are thinking in western grouping of tenses on a verb conjugation of a different language. It is not the mood that is not inferred here. It is the property of the verb. Verb itself can be used to communicate the same information with a single word "Gitmisim" just as valid ("I apparently went there"). So where is the tense of a single word if it does not have tense in it? How do turkish people communicate without a tense using a single word just with the mood?

As a former drummer who bashed way too many Chinas without proper ear protection, I had some scary tinnitus for quite a while. My advice;

- 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.

Yet another title to drive embedded device designers and control engineers up the wall.

Why don't you make up your own bullshit words instead of randomly picking stuff from other places? That's not even multiplexing.

You misspelled oligopoly. My guess from your comment is that you don't have a handle on how academia works, which is perfectly fine. You don't have to. But then don't hold such strong opinions because what you wrote is not even wrong.

"Music theorists tend to bombard their audience with more information than nonexperts can swallow in one sitting." groaned the mathematician, in cognitive dissonance.

Why should complex numbers need justification to be native type? If you need to do serious computation, you need them. If you say Zig is not for number crunching which, say, Java explicitly decided then fine otherwise searching for a reason for complex number tells me that you don't do any numerical programming which is fine but asking for justification makes no sense. Why is any other thing in the language justified? float64 is just two float32. Why stop at float64 why not float128 float256?

I'll paste the same comment here as I did in the sibling; Why should complex numbers need justification? If you need to do serious computation, you need them. If you say Zig is not for number crunching which Java explicitly decided then fine otherwise searching for a reason for complex number tells me that you don't do any numerical programming which is fine but asking for justification makes no sense. Why is any other thing in the language justified?

True, but column-major by default and 1-indexed unfortunately. Still quite nice that they are addressing these challenges head-on early stage unlike other new langs. I guess they had their share the pain like the rest of us.

Why did not I think of that, shame on me.

You are essentially necromancing the ISO C99 discussion that happened already. Here is an answer that, after 25 years, is still wrong https://learn.microsoft.com/en-us/cpp/c-runtime-library/comp...