Slashdot Mirror
Is FORTRAN Still Kicking?
Algorithm wrangler queries: "I'm beginning to wonder if I should invest the time in learning FORTRAN. Although it is, arcane it seems to be the best tool when it comes to demanding optimization tasks and heavy computations. C/C++ does not cut it for me - it is simply too easy to make mistakes and I find myself using half of my time hunting bugs unrelated to the problem at hand. Additionally, although tools like Matlab exist they don't provide the power that justify the huge price tag they carry. I find any script based language (Matlab, Numeric Python, Scilab) to be inadequate as soon as it is necessary to use loops to describe a problem and using such tools for recursive systems can be a real pain. As another data-point, the Netlib repository seems to be very FORTRAN oriented, and it is a true gold mine when it comes to free routines for solving almost any computing task. What bothers me though is that FORTRAN code is really ugly and the language lacks almost any modern day language feature (I know about Fortran 90 but it is not much nicer than F77, and no one seems to use it). Can it really be true that the best tool we have for heavy duty computing is a 25 year old language, or have you found anything better - free or non-free?"
Just because I said "floating point" doesn't mean I use IEEE floating point formats. I'm using BCD. Not that it matters. You can most certainly keep all floting point noise below your precision, even when using IEEE floating point numbers. The problem comes up only when poor programmers who are unaware of rounding error perform iterative calculations without accomodating the imprecision. It is certainly NOT wrong to use floating point for financials. You just have to know what you are doing. In this sense, it is like all other programming. Ignorance makes errors.
If you wish to use only those programming tools which do not permit the programmer to produce an error, you will never write a line of code. Guess what? You can get it wrong using only integers. Perhaps we should do all calculation on paper with pencils? Wait, do you mean you can have errors there too? I guess we should simply never do arithmetic. We should just use random numbers. That will at least produce errors that are statistically equal on either side of correct. Yes, based on your view, that would be the best solution.
Grow up, get real (pun intended).
Some years back, at a university that will remain unnamed (so you might think it's yours ;-), a bunch of us grad students decided to instrument the Fortran compiler that was used for most of the number crunching on the big department monster machine. The hardware handled integer overflows by setting a flag bit, which then had to be tested by a separate opcode, and the Fortran compiler didn't generate this test. (For floating point, there was an interrupt that couldn't be ignored.)
The instrumentation added a test that recorded the overflow, let the computation continue, and wrote some results to an accounting file.
What was found was that almost exactly half the Fortran runs produced at least one output number that was wrong due to an undetected overflow.
When this was publicised, a survey of Fortran users was done. They were asked whether the compiler should test for overflow if such a test would take an extra opcode and slow the program down. around 90% of the users said that such tests should not be done if the program would run slower.
This taught us an important lesson about the Fortran user community. And note that in the replies here, a lot is made of Fortran's optimizations. Now you know what that means.
Around the same time, there was one of several analyses of the Fortran runtime libraries on IBM 370 mainframes, which are still in wide use for big number-crunching applications. The analysis showed that the double routines were accurate to only float precision over roughly half the range of their arguments. At the time, these routines had been in widespread use for maybe two decades.
When a Fortran programmer uses double rather than float, it usually means that the computations needs the extra precision, and float doesn't have good enough precision to give correct output. For users to accept a Fortran that can't do doubles correctly half the time is another good sign of the nature of this user community.
So in general, Fortran users seem to use it because they consider efficiency more important than correct results.
I wonder if Enron's accountants use Fortran?
Those who do study history are doomed to stand helplessly by while everyone else repeats it.
IDL's graphics drawing routines are subpar, performance-wise. Don't use it if you need to optimize for speed...
It's also has a weird and clunky GUI toolkit. It's great for slapping something together quickly for analyzing and manipulating stuff, but I have reservations about using it as a general purpose tool.
WE ARE NOT TALKING ABOUT PCs YOU FUCKWIT
CPU time on really big iron is charged for, time is money.