Functional Fortran(wavebitscientific.github.io)
wavebitscientific.github.io
Functional Fortran
https://wavebitscientific.github.io/functional-fortran/
25 comments
Not directly related to the article, but given a green field, what project qualities would lead one to choose Fortran as a tool to solve the problem over anything else?
Look at where it is used. It's still a better choice for HPC and deep numerics work than virtually anything else. Which is really remarkable when you stop to think about it.
Sure you could probably eke out faster code if you're a mentat and really good at C, or know the internals of a C++ compiler very well. But then you have to be good (and find good collaborators), and you pay the toll of dealing with pointers and memory management. I'm pretty sure I could stand up, say, a fast Gentleman's method using Fortran faster than in C++. And I'm certain I can get a large team of numerics guys to do, say, climate simulations faster and better in Fortran than C++.
Sure you could probably eke out faster code if you're a mentat and really good at C, or know the internals of a C++ compiler very well. But then you have to be good (and find good collaborators), and you pay the toll of dealing with pointers and memory management. I'm pretty sure I could stand up, say, a fast Gentleman's method using Fortran faster than in C++. And I'm certain I can get a large team of numerics guys to do, say, climate simulations faster and better in Fortran than C++.
What exactly is it about Fortran that makes it better for an HPC env and numeric computing than c++? Or is it more just an available libs/history question?
The big thing I always see is that it has a few important limitations, and those limitations mean that extra optimizations can be used.
https://stackoverflow.com/a/146186
https://stackoverflow.com/a/146186
That's a fantastic SO answer.
> What exactly is it about Fortran that makes it better for an HPC env and numeric computing than c++?
Fortran is an easy language to learn. A domain expert doesn't need to spend months or years to learn C++, they can write safe and performant Fortran code in almost no time.
Fortran is an easy language to learn. A domain expert doesn't need to spend months or years to learn C++, they can write safe and performant Fortran code in almost no time.
Apart from string processing and a few other warts, Fortran is surprisingly similar to working with Numpy - avoiding explicit loops and doing operations on arrays, slicing notation, etc. It can make a lot of computational code really easy to write and easy to read, thus easy to understand and get right.
Which makes sense when you recall ForTran = Formula Translator. It's literally designed as language where you should be able to write code that's one-to-one with your equations.
Which makes sense when you recall ForTran = Formula Translator. It's literally designed as language where you should be able to write code that's one-to-one with your equations.
I recently selected Fortran for a greenfield project. The reasons were primarily (1) speed, (2) clean mathematical syntax, especially for elemental multi-dimensional array math, (3) clean array slicing syntax, and (4) arbitrary array indices[0] result in cleaner code for my use cases.
People normally think of Fortran as being inscrutable spaghetti code, but for me using Fortran results in the cleanest, fastest code.
[0] Fortran arrays are 1-indexed by default, but can technically use any integer, including 0, or negative numbers. It's trivial to have, say, an array indexed from -7 to +7:
People normally think of Fortran as being inscrutable spaghetti code, but for me using Fortran results in the cleanest, fastest code.
[0] Fortran arrays are 1-indexed by default, but can technically use any integer, including 0, or negative numbers. It's trivial to have, say, an array indexed from -7 to +7:
real :: array(-7:7)Arbitrary indexing is really the one true way! It makes working with subsets of arrays simple, I wish I could use it in more languages.
This is something that's really nicely supported in Julia: https://github.com/JuliaArrays/OffsetArrays.jl
Most Algol derived languages (Wirth et al) follow that path and Basics.
FORTRAN is pervasive in earth and space sciences. There are large models that have been built and extended for as long back as the 50s and 60s.
I’m not sure I would have been inclined to use something like functional FORTRAN when I was working on that stuff since mostly the models don’t change too much, and most new code is some kind of glue between parts.
I’m not sure I would have been inclined to use something like functional FORTRAN when I was working on that stuff since mostly the models don’t change too much, and most new code is some kind of glue between parts.
I know at least one person in quantitative finance that is starting a greenfield project in Fortran. He says it works and has great performance, doesn't get in the way and appeals more to people with science rather than programming backgrounds.
I have collaborators who write really terrible C++. They write much better Fortran. This is for code that computes straightforward equations.
Modern Fortran is still popular for computationally-heavy economics. C and C++ never really caught on because it's irrational to use one of those languages when Fortran will do. Julia, on the other hand, is now gaining ground because it's both fast and usable by humans.
Lots of libraries available for all kinds of scientific work that require supercomputers to be useful.
Also, I've been told that FORTRAN makes it easier to write fast scientific code than C due to pointer aliasing (or something in those lines).
Also, I've been told that FORTRAN makes it easier to write fast scientific code than C due to pointer aliasing (or something in those lines).
Pointer aliasing is not valid in FORTRAN, so the compiler has the freedom to make some optimizations that a C compiler can't.
Plus the arrays in Fortran would be much nicer to use than C.
Anything to do with scientific computing or numerics can probably be done well and about as fast as it can be done in Fortran. If you look up ACM TOMS people are still submitting Fortran implementations.
The traditional reason is if you are doing a heavy numerical simulation or not, but in practice I'm guessing it is down to the preference of whoever is in charge.
If you don't know Fortran, I wouldn't recommend you learn it to write a GUI app, but if you do know fortran and want to learn low level systems programming you can use it to write a GUI.
If you don't know Fortran, I wouldn't recommend you learn it to write a GUI app, but if you do know fortran and want to learn low level systems programming you can use it to write a GUI.
Not as a single tool, but if I'm using numerical libraries I need to be accurate, and not have another unpleasant experience with numerical methods. That said, I can usually get by with the prebuilt libs
If you have Matlab code that's mostly expressed in matrix multiplications, porting to Fortran 95 or newer is quick (a lot of copy-pasting even) and makes your stuff fast and compiled.
Original thread: https://news.ycombinator.com/item?id=13024702
Does a recursive fold use physical recursion (i.e. requires linear stack space)? Can Fortran compilers resolve tail recursion?
Most Fortran compilers are also C/C++ compilers, so sure.
I've never seen any Fortran code in the wild that does that, though.
I've never seen any Fortran code in the wild that does that, though.