News for hackers. Stuff that matters.
Re:Fortran by ribit on Monday August 28, 2023 @07:10AM (#37292316)
I fully agree with you that scripting languages are a great fit for scientific computing. But I just don't see how this is a case for Fortran.

R or Python are still much easier to use and give you the same access to high-performance numerical accelerators via BLAS/LAPACK backends. And if you need a low-level language (e.g when developing an optimised routine that solves a specific problem), I would use a high-performance widely supported systems programming language like C++ or Rust.

Fortran seems to be around mostly for legacy reasons. And I am not sure that legacy considerations alone make a good foundation.

Re:Fortran by galangalalgol on Monday August 28, 2023 @07:18AM (#37292377)
BLAS/LAPACK are written in fortran was the point I think. There are eigen and nalgebra certainly, but neither exports as cleanly to python, and neither is significantly (if at all) faster.

CuBLAS on the other hand makes a lot of sense to use from python if you have the right hardware.

Re:Fortran by xmcqdpt2 on Monday August 28, 2023 @07:42AM (#37292565)
The reference implementation of BLAS that you should absolutely not use is written in Fortran. The actual implementations are written in C/C++/ASM.

That's not to say you should use C yourself, memory management is a lot nicer in Fortran, for multidimensional arrays. You can stack allocate arrays inside functions and modern fortran has move semantics. Arrays are contiguous even if they have multiple index. It's generally a nice language for math, has good C API integration (both as caller and callee) and compiles down to small libraries without runtimes.

Re:Fortran by galangalalgol on Monday August 28, 2023 @09:17AM (#37293471)
Thanks! I did not most any of that. Except for that it is good at math.
Re:Fortran by enriquto on Monday August 28, 2023 @07:25AM (#37292425)
Loops in Python are excruciatingly slow, for no reason. Some algorithms are naturally written using loops, and Python makes this very uncomfortable, forcing you to rewrite your algorithm in a non-natural way. I hate writing numerical code in Python due to that; it just feels uncomfortable.

For scientific computation I just need multi-dimensional arrays of floats and fast loops. Fortran has both of these things natively. Python has neither.

Re:Fortran by ribit on Monday August 28, 2023 @12:48PM (#37296988)
I prefer vector types for this kind of stuff, as they are more compact than loops and naturally lend themselves to auto-vectorisation. In the end it comes down to the programming style preference.
Re:Fortran by metal_am on Monday August 28, 2023 @04:33PM (#37300053)
A lot of the code used in scientific computing cannot be vectorized because the latter loop is dependent on the former loop (like time stepping in a simulation). It’s not really a programming style preference.
Re:Fortran by goerz on Tuesday August 29, 2023 @06:27AM (#37305574)
C++ and Rust don’t really have good semantics for scientific computing (linear algebra). They’re great for many other domains like “system’s programming”, where Fortran doesn’t compete, of course. The only language that’s similarly (in fact, more) expressive as Fortran for scientific computing today, as well as holding up for performance, is Julia