> > It multiplies two matrices. C can't do that. In C, I'd have some unreadable matrix64_multiply(a, b).

> In C you get BLAS which provides functions like ?gemm, a BLAS level-3 function >which is literally stands for general matrix-matrix product.

> Hardly cryptic.

Seriously? The signature for dgemm is

    void cblas_dgemm(const CBLAS_LAYOUT layout, const CBLAS_TRANSPOSE TransA,
                     const CBLAS_TRANSPOSE TransB, const CBLAS_INT M, const CBLAS_INT N,
                     const CBLAS_INT K, const double alpha, const double  *A,
                     const CBLAS_INT lda, const double  *B, const CBLAS_INT ldb,
                     const double beta, double  *C, const CBLAS_INT ldc)

Maybe you have a loads of free time, but I don't want to memorize that function signature when I could just type A @ B.

> Seriously? The signature for dgemm is (...)

The signature of gemm is trivial if you're aware of the basics of handling dense row-major/column-major matrices.

https://www.intel.com/content/www/us/en/develop/documentatio...

https://www.netlib.org/lapack/explore-html/db/dc9/group__sin...

I haven't met a single person who did any number crunching work whatsoever who ever experienced any problem doing basic matrix-matrix products with BLAS. Complaining about flags to handle row-major/column-major matrices while boasting about being an authority on number crunching is something that's not credible at all.

You sound a lot like me, when I was a teenager.

I don't actually mind memorizing these things if I'm doing this 60 hours per week. I used to be quite good at some of the C++ STL numerics libraries. I took the same perverse pride some folks here apparently do in knowing these things in- and-out.

However, most of code is about being able to read it and modify it, not write it. Equations are sometimes hard enough when they look like equations. If you've got a call like that in your code, that's going to be radically harder to understand than A*B.

That's not to mention all the clutter around it, of allocating and deallocating memory.

One of the things C++ programmers don't typically understand are the types of boosts one gets from closures, garbage collection, and functional programming in general, especially for numerics. I recommend this book:

https://en.wikipedia.org/wiki/Structure_and_Interpretation_o...

In it, you'll see code which:

- The user writes a Lagrangian

- The system symbolically computes the Lagrange equations (which are derivatives of the above)

- This is compiled into native code

- A numerical algorithm integrates that into a trajectory of motion

- Which is then plotted

All of this code is readable (equations are written in Lisp, but rendered in LaTeX). None of this is overly hard in a Lisp; this was 1-3 people hacking together, and not even central to what they were doing. It'd be neigh-impossible in C or C++.

Those are the sorts of code structures which C/C++ programmers won't even think of, because their impossible to express.

(Footnote: Recent versions of C++ introduced closures; I have not used them. People who have express they're not "real closures.")

Interesting... I would think symbolically deriving the Euler-Lagrange equations from the Lagrangian would be quite hard in practice.

That's the shocking thing. It's totally not hard in a Lisp. I could write the code for that symbolic derivation in an evening, tops.

The hard part is the compiler. The somewhat hard part is the efficient numerical integrator (if you want good convergence and rapid integration). The symbolic manipulation is easy, once you know what you're doing. If you want to know what you're doing, it's sufficient to see how other people did it:

https://mitpress.mit.edu/sites/default/files/titles/content/...

And if you haven't seen it:

https://mitpress.mit.edu/sites/default/files/sicp/full-text/...

If you're dumb like me, and can't write a compiler or an efficient numerical integrator in your spare time, having this interpreted and using a naive integrator is still good enough most of the time. Computers are fast. The authors of the above proved the motion of the solar system is chaotic with a very, very long, very, very precise numeric integration on hardware from decades ago, so they have super-fancy code. For the types of things I do, a dumb integration is fine.

Once you've seen how it's done, and don't mind lower speed, that's trivial in any language with closures (e.g. Python or even JavaScript). If you want to swing a double-pendulum, or play around with the motion of a solar system over shorter durations, it's easy.

And using the tool is even easier. Look at SICM (linked book). The things that look like code snippets are literally all the code you need.

The system, if you want it:

https://groups.csail.mit.edu/mac/users/gjs/6946/installation...

Wow, I can't believe I've never heard of this book (SICM, not the wizard book). Seems incredibly cool.

That said, I'll maintain that my initial skepticism was somewhat justified given that the derivation relies on a pre-written symbolic manipulation/solver library (scmutils) so it's not quite 'from scratch' in a Lisp ;) although I believe that you could write such a library yourself, as SICP demonstrates.

As a side note, it looks like I can't go through this book because I have an M1 Mac, which GNU Scheme doesn't support :(