4 ms·

> 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

> 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/documentation/onemkl-developer-reference-fortran/top/blas-and-sparse-blas-routines/blas-routines/blas-level-3-routines/gemm.html 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__TutorialMatrixArithmetic.html 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.

patrick451 4y ago
> > 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.
- blagie 4y ago
  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_of_Classical_Mechanics 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.")
  - whimsicalism 4y ago
    Interesting... I would think symbolically deriving the Euler-Lagrange equations from the Lagrangian would be quite hard in practice.
    - blagie 4y ago
      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/sicm_edition_2/book.html 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/book/book-Z-H-16.html#%_sec_2.3.2 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.html https://groups.csail.mit.edu/mac/users/gjs/6946/installation...

patrick451 4y ago

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

blagie 4y ago
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_of_Classical_Mechanics 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.")
- whimsicalism 4y ago
  Interesting... I would think symbolically deriving the Euler-Lagrange equations from the Lagrangian would be quite hard in practice.
  - blagie 4y ago
    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/sicm_edition_2/book.html 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/book/book-Z-H-16.html#%_sec_2.3.2 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.html https://groups.csail.mit.edu/mac/users/gjs/6946/installation...