Modern FORTRAN looks more like Matlab than FORTRAN 77. The syntax has been completely overhauled since at least ‘95.
For a while I was translating my Matlab codes to FORTRAN; it was surprisingly easy. But I was being too naive with array resizings in Matlab and most of the speed gain (which was like 2-3 orders of magnitude) could be achieved in Matlab itself by preallocating memory.
To this day I have the nervous tick of initializing arrays with zeros even in numpy.
> To this day I have the nervous tick of initializing arrays with zeros even in numpy.
I dunno - I wouldn’t call that a nervous tick. If you know or have a good idea of how much memory you need, then it only seems polite to let the runtime/OS know ahead of time.
I think of it like RSVP’ing to a dinner party. Host is very appreciative when they know how many people they’re serving.
Note there's also `np.empty(size)` if you know you're going to initialize all the values in a later step, in which case it can skip assigning zeros to every element.
Fortran users of HN - what are the best resources (online / books / ...) to pick up Fortran in 2019? Are there any open source codebases you'd consider as good to read through?
I have the book Modern Fortran Explained by Metcalf. It does a great job of providing modern examples of traditional code as well as examples of the new features.
Yep -- old-school fixed-format Fortran had one column for the "c"(omment) marker, seven for the statement number (maybe 5 plus spaces on either side?), then 72 for the code before you fell off the end of the punch card.
No, you get all 7 spaces for the statement number; live it up a little!
Don't know if it's still the case, but in FORTRAN IV you don't need spaces between keywords and variable names. So when the compiler sees "FORI=2" it has to look still further ahead to decide if this is a for-loop (FORI=2TO9DO) or an assignment to a variable named FORI. Decidedly not a context-free grammar; you can't even figure out the tokens without the ad-hoc parser getting involved.
I'm still using a program and occasionally updating it that's mostly in FORTRAN 77. Originally written in FORTRAN IV. Ah, gotta love the nuclear industry. Good code though.
Cool. The WATFIV (Waterloo FORTRAN IV) was what I used in my first college programming class, on a pair of Amdahl 470 (IBM 370 compatible) mainframes, but as a high school kid I had taught myself BASIC and Pascal on the Apple II. At the time, I felt like FORTRAN was a step back in time, but I have more appreciation for it now.
The most notable thing I spotted is they have deleted the arithmetic IF from the language, which must be one of the more characteristic features of classic FORTRAN.
I agree. The non intuitive reason stated is that there is a standard that specifies a sign for zero, and numeric IF doesn't distinguish between them, and it depends upon labels which are hard to optimize.
Another notable capability is that procedures default to recursive and there is a way to state they are non_recursive.
What's the degree of backward compatibility with FORTRAN releases? I imagine most FORTRAN codebases as being huge and old, so it makes me wonder how many can adopt the latest versions.
Each new standard usually removes a very small number of features, but Fortran 2018 is mostly a superset of Fortran 77. Most compilers retain absolute backward compatibility, so they can compile a superset of Fortran 66 to 2018, and often some custom language extensions on top.
I’ve compiled fortran code from approx 1965. Works the same today. I don’t know of anything that is as compatible as standard Fortran code. That being said, quite a few vendor extensions are floating around, and often old codebases rely on a few of these.
In my experience nearly all standard old code will still compile just fine, except code which relied on compiler-specific extensions and directives. Unfortunately, there does tend to be a lot of code out there using these proprietary directives.
Things like metacommands [0] will need to be converted to something standard (or removed) to work with modern compilers.
I've been really interested in learning Fortran for a while- I work doing a lot of computational stats/ML and typically my tools are python, R, or Golang. Is there any use-case for Fortran in production settings or should I just accept it would be purely a personal satisfaction project?
IMO if you're working with large, multi-dimensional arrays and seamless parallelization (shared or distributed memory) is a plus, I've yet to see a language or framework do it with less effort. Speaking as a long-time numpy user and fan here. :)
For an example of use in production, my business [0] is built around running ~1M lines of parallel Fortran (public domain code) in the cloud. There are many many other uses but tend to be less visible -- under the hood of other software, banking systems, many DOE and DOD projects etc.
It's very fast and there is a new Manning book about to come out on Modern Fortran that is all about parallel Fortran.
In addition to being fast, I find it considerably easier to read than C++ as it isn't as low level and doesn't have as much noise (at least the later versions like Fortran 90).
It also makes writing numerical code easy as it was truly built for high performance scientific computing.
A lot of older scientific projects run on Fortran and although I know some projects that were migrated to C++, it wasn't due to any defect from the language besides it not being taught very often in colleges now outside of some astrophysics classes where it was once a mainstay in engineering and science curriculums.
There are several compilers available, but a lot of them are commercial and some are expensive. There are free versions as well of course.
Though the main reason (for a while) that Fortran compilers could produce faster code was that they were allowed to assume that variables (including arguments to your functions) don't alias each other.
I don't understand the "Though" part of this. The only reason any compiled language may be faster than another is because a compiler knows/assumes more about the code (either through users specification, or restrictions of the language).
The advantages of the proprietary compilers are quite over-sold. GNU Fortran is pretty good, and distinctly more reliable than some. (I don't have experience of the LLVM-based ones.)
Fortran 77 was the language I used in my first job in 92 on DOS and Unix. Can't see the benefits over other languages like C, Go, Python though. Unless you've got some specific high performance floating point ops requirements?
Quite a few scientists and engineers have those requirements. I wouldn't choose it for writing a web server or text processing, but Fortran is actually a pretty nice language for dealing with numbers and arrays. It also has decades' worth of well-tested numerical libraries, which can be very subtle and hard to get right.
Sort of, but we haven't figured out how to make language boundaries disappear. For example, row- vs. column-major ordering of arrays is an eternal pain when communicating between C and Fortran.
Numpy, R, Matlab, etc. are good scripting languages for a lot of Fortran, but if you ever need to peek under the hood...
"Sorry for digging up an old thread but it seems that even in 2015, Fortran is being used a lot.
I just came across this (alternate link) list which basically is a list of 13 codes approved by DOE's OCLF facility to run on the 300-petaFLOPS Summit machine which will be made available to researchers in 2018. I tried to find the main language used for the code (based on a quick google search) and here is what I found:
XGC Fortran
SPECFEM Fortran
ACME Fortran (Bunch of climate codes)
DIRAC Fortran (Mostly)
FLASH Fortran
GTC Fortran
HACC C/C++
LS-DALTON Fortran (some C)
NAMD C/C++
NUCCOR Fortran
NWCHEM Fortran
QMCPACK C++
RAPTOR Fortran"
Note: QMCPACK is written in C++ but depends on LAPACK which is again Fortran.
Another example I've given before is the usage statistics for the UK "tier 1" system: //www.archer.ac.uk/status/codes/. Six of the top ten are Fortran that month (I think -- I'm not positive about NEMO). That's probably vaguely representative of typical general purpose HPC systems.
For a while I was translating my Matlab codes to FORTRAN; it was surprisingly easy. But I was being too naive with array resizings in Matlab and most of the speed gain (which was like 2-3 orders of magnitude) could be achieved in Matlab itself by preallocating memory.
To this day I have the nervous tick of initializing arrays with zeros even in numpy.