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

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

Also, anyone doing any remotely serious number crunching/linear algebra work is well aware that you need to have control over which algorithms you use to run these primitive operations, and which data type you're using.

> I used to do numerics in C++, and in C before that. It's at least a 10x difference in programmer productivity stepping up to Python.

I'm rather skeptical of your claim. Eigen is the de-facto standard C++ linear algebra toolkit and it overloads operators for basic arithmetics.

I'm not sure your appeal to authority is backed up with any relevant experience or authority.

https://eigen.tuxfamily.org/dox-devel/group__TutorialMatrixA...

I'm not sure your appeal to authority is backed up with any relevant experience or authority. It's ok if you like Python and numpy, but don't try to pass off your personal taste for anything with technical merit.

> > 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 :(

> the number of bugs goes way up

In case you are forced to use the unreadable long-named unintuitively-syntaxed methods, add unit tests, and check that input-output pairs match with whatever formula you started with.

Yet, Python (and most of her programmers including data scientists, of which I am one) stumble with typing.

    if 0.1 + 0.2 == 0.3:
        print('Data is handled as expected.')
    else:
        print('Ruh roh.')

This fails on Python 3.10 because floats are not decimals, even if we really want them to be. So most folks ignore the complexity (due to naivety or convenience) or architect appropriately after seeing weird bugs. But the "Python is easiest and gets it right" notion that I'm often guilty of has some clear edge cases.

Why would you want decimals for numeric computations though? Rationals might be useful for algebraic computations, but that’d be pretty niche. I’d think decimals would only be useful for presentation and maybe accountancy.

Well, for starters folks tend to code expecting 0.1+0.2=0.3, rather than abs(0.3-0.2-0.1) < tolerance_value

Raw floats don't get you there unfortunately.

If you want that you should use integers. This seems to be a misalignment of expectations rather than a fault in the language.

Other people have posted other examples but it’s not possible to represent real numbers losslessly in finite space. Mathematicians use symbolic computation but that probably is not what you would want for numerics. I could see a language interpreting decimal input as a decimal value and forcing you to convert it to floating point explicitly just to be true to the textual representation of the number, but it would just be annoying to anyone who wants to use the language for real computation and people who don’t understand floating point would probably still complain.

Edit: I’ll admit I have a pet peeve that people aren’t taught in school that decimal notation is a syntactic convenience and not an inherent property of numbers.

They also expect 1/3 + 1/3 + 1/3 == 1. Decimals won't help with that.

That's slightly different in that most programmers won't read 1/3 as "one third" but instead "one divided by three", and interpret that as three divisions added together, and the expectations are different. Seeing a constant written as a decimal invites people to think of them as decimals, rather than the actual internal representation, which is often "the float that most closely represents or approximates that decimal".

Correct! Many python users don't know about this and similar libraries that assist with data types. Numpy has several as well.

It is not a Python thing, it is a floating-point thing. You need it if you want hardware support (CPU/GPU) for non-integer arithmetic in any language. Otherwise, you have decimal, fractions, sympy, etc modules depending on your needs.

https://docs.python.org/3/tutorial/floatingpoint.html

This is an issue for accountancy. Many numerical fields have data coming from noisy instruments so being lossy doesn't matter. In the same vein as why GPUs offer f16 typed values.