This is cool. Good to see. Thanx for posting this. If someone is coding some serious math hackery, drill down into the app and you'll often find someone's variant/version of the old IMSL library routines, written - in Fortran - back in the 1960's. Why? Because that code was extensively tested and was deemed trustworthy. And even better - just went to my bookshelves and found it: "Optimization Techniques With Fortran" - James L. Kuester, Joe H. Mize, McGraw-Hill, 1973, ISBN 0-07-035606-8. It's just an awesome book - it's 9inches by 11 inches, 500 pages chock full of detailed explanations of many of the state-of-the-art circa 1973 optimization techniques for search methods, linear and quadratic programming tricks, least-squares (linear and non-linear methods), dynamic programming (a math technique for making a series of interrelated decisions), and so on. The book has code, examples and detailed explanations - with numerical examples - and flowcharts even, to explain exactly how the code works, and what the program is actually doing.
And its all Fortran - some of it IBM/360 Fortran - all in Courier font that's easy to read and use.
I had a client that just typed in all the code for a Simplex LP program, and used it to construct a big optimization solution for how to structure the re-investment actions of a large bond portfolio in a treasury department of a big organization.
Before there were neural networks and image-hacking, there was the gritty math-hacking to optimize big gobs of interrelated stuff that had to happen in the right order. It was almost always done in Fortran, and I suspect a lot of it still is. (And if it was not done in Fortran, it was done in APL. Ask an Actuarial scientist, if you doubt this..)
Please don't laugh at Fortran. It can not only help you fly your spaceship to another planet (and get you home again!), it can also make you (and your client) rich, since you can build solid, bulletproof code from those old libraries that just works, and hence create flaw-free solutions to really critically important applications.
This proposed extension looks useful.
(https://github.com/wch/r-source says that's 23% of the source. It includes vendored libraries, like a 5MB .f of LAPACK code. I bet a lot of the C code in R was f2c'd at some point in the past)
Oh man, just seeing those letters—I M S L—brought back the distinct smell of the IMSL documentation in the UIC computer lab in the 80s, which along with a lot of other mainframe documentation was on special racks where three ring–punched documentation could be read (but not actually brought to a terminal where it could be useful).
Although they weren't built into the language, conditional expressions were first used in Fortran in 1957 by John McCarthy: "I invented conditional expressions in connection with a set of chess legal move routines I wrote in FORTRAN for the IBM 704 at M.I.T. during
1957-58. This program did not use list processing. The IF statement provided in FORTRAN 1 and FORTRAN 2 was very awkward to use, and it
was natural to invent a function XIF(M,N1,N2) whose value was N1 or N2
according to whether the expression M was zero or not. The function shortened many programs and made them easier to understand, but it had to
be used sparingly, because all three arguments had to be evaluated before
XIF was entered, since XIF was called as an ordinary FORTRAN function
though written in machine language. This led to the invention of the true
conditional expression which evaluates only one of N1 and N2 according to
whether M is true or false and to a desire for a programming language that
would allow its use." From http://jmc.stanford.edu/articles/lisp/lisp.pdf
Thanks. you helped confirm I must have learned some early state of F77 in 76/7. Since F77 was 1978 and I left school in 78, it can't have been full standard. I was sure I remembered an ELSE so now I wonder if this is a mis-memory, or languages intercepted this somehow. (cards on an ICL 1900 system)
One nice thing about lazy languages is you get the desired operator behavior for conditional operators, short-circuiting logical operators, etc “for free” without having to build it into the language.
Well-disposed as I am towards laziness, you may well not want short-circuiting, depending on the application. I just re-wrote the C implementations of logical reductions using bitwise operators instead to && and || to get them vectorized -- avoiding "conditional in loop". (They're Fortran-callable.)
Incidentally, gfortran treats the reduction like C, which seems a deficiency as the standard allows it not to.
Doesn't Fortran 90 have the MERGE(IFTRUE,IFFALSE,CONDITIONAL) function as standard which is similar to the XIF used here? (as usual, Fortran chooses some weird names for its functions).
Perhaps the difference with the conditional discussed here is that in a function all the arguments are usually calculated before evaluation, so the conditional may avoid an error if one of the arguments can be invalid depending on the condition. It's a bit unclear from the proposed language addition, however.
I've always thought the conditional ternary operator would map really well to masked vector operations. Since those were around in the old Cray machines, I was always confused as about the absence of ternary op in Fortran. It is a pretty well designed language, so I'm sure I'm missing something, but it seemed odd. Happy to see it show up now!
I’m no C language lawyer, but it’s hard to imagine that sort of voodoo won’t trigger some kind of undefined behaviour that’ll cause the optimizer to erase your program at best and summon nasal demons at worst.
An interesting question is whether the continuing modernization of fortran will at some point enable it to become the "React/JS" of data scientists and assorted tensor crunchers. Fortran had built-in vector operations since fortran 90 which could have made it a natural choice for programming GPU's. Today there is a complex ecosystem of python, julia, R, c++, fortran, but none of which seems to offer a royal route to "mass market GPU programming".
Is the ternary conditional just for the syntactic ease or there are some performance reasons for this?
I understand there are conditional assignment instructions, though optimizer could likely choose these already. Also branching prediction may take care of such assignments as well.
Fortran has no means for preventing execution of subexpressions in a portable way. The standard allows a compiler to short-circuit .AND./.OR. and to evaluate only one of the first two arguments to a MERGE with a scalar condition, but it is not required and a programmer can’t depend on it. Rather than strengthen the guarantees of short-circuiting and non-evaluation of existing constructs (neither of which would have invalidated any portable code), the geniuses of J3 decided to add more syntax.
The word of greatest value in the headline is “expressions”. There are conditionals in FORTRAN but now you can have a conditional that evaluates to something.
Also depends on what you assign to. If you read an if/else statement, you have to check whether both branches assign to the same value. If that’s a complex expression, that isn’t trivial.
Often such blanket statements are made by people who know little about the current state of the language they are denouncing. I am happy to use modern Fortran.
I see this type of comment often when Fortran is mentioned, and it puzzles me. What are computers for? Mainly for games and websites, with scientific computation an obscure niche? I don’t think so. Computers are for modeling the climate, predicting the weather, simulating the economy, calculating the merger of galaxies, and designing airplanes. For any of these, the high-performing languages are Fortran, Julia, C, and C++. That’s it. Lisp, Erlang, and Smalltalk are wonderful languages, but not for this.
When I do Astro app I found that you want accurate calculation you need fortran. Science spill over to other areas. In fact if you check around many languages and libraries use fortran for say matrix and many other manipulation. You use matrix nearly everywhere.
Btw, My first lecture in 1979 on computer science the lecturer asked exactly this question. What is the use? Why Fortean not dead by now? Why should anyone learn fortran … ba la ba la.
No chance but I wish he had taught me lisp and c instead of Basic … even if not fortran.
React is a responsive framework, not a compute lib. It's a joke.
Getting offtopic here from FORTRAN, but there have been several attempts at numeric libraries in javascript (math.js, numjs), they are either lightweight, or unmaintained and in a sorry state, or require async execution that expect remote hardware (Googles tensor libs) which makes them a bit difficult to use in a general setting.
Hopefully WebASM will result in a native numpy-like library for JS because numpy is a very well-thought-out library and interface, it's really addictive.
Before there were neural networks and image-hacking, there was the gritty math-hacking to optimize big gobs of interrelated stuff that had to happen in the right order. It was almost always done in Fortran, and I suspect a lot of it still is. (And if it was not done in Fortran, it was done in APL. Ask an Actuarial scientist, if you doubt this..) Please don't laugh at Fortran. It can not only help you fly your spaceship to another planet (and get you home again!), it can also make you (and your client) rich, since you can build solid, bulletproof code from those old libraries that just works, and hence create flaw-free solutions to really critically important applications. This proposed extension looks useful.