Fortran adds conditional expressions(j3-fortran.org)
j3-fortran.org
Fortran adds conditional expressions
https://j3-fortran.org/doc/year/21/21-157r2.txt
14 comments
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.
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.
Sample syntax:
y = ( i>=1 .And. i<=Size(a) ? a(i) : -Huge(y) )
Sorry, not familiar with Fortran at all. Did ternaries already exist, and this just adds assignment or is the ternary new too?
The ternary is new. Before, one could use the merge intrinsic function to write
y = merge(a(i), -Huge(y), i>=1 .And. i<=Size(a))
y = (boolean ? expression_1 : expression_2)
[deleted]
_g2ou(6)
too little, too late! I am super happy with React+Js nowadays..
Interesting to see how much slower is JS when compared to Fortran for matrix operations, no idea how to compare React to 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.
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.
I have written interfaces in Fortran 77 back in the 80's
It’s not fast but I’ve found “algebrite” to be a good CAS for JavaScript that I can break out anytime I need dot products.
to be honest, this was just a very stupid joke. i guess there is no good reason to compare the two.
[deleted]
Ok cool but is React+Js really a competitor to Fortran…?
Both are Turing complete, so it is the case
I don't know why people still bother using Fortran, Magic the Gathering obsoleted it decades ago.
I prefer Excel to both, which is also Turing complete.
What about CSS?
Better go with TeX if you're going into the Turing complete typesetting language niche, a Knuth product has more street cred.
how do people currently write conditional statements?
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.
The current equivalent to the one-liner I presented is
if (i>=1 .And. i<=Size(a)) then
y = a(i)
else
y = -Huge(y)
end ifThis to me looks more readable than a one liner
Depends on the language I guess. For me this is easier to read (and reason with) in JS:
Besides, it blends well with functional programming where side effect are better avoided.
const y = (i <== 1 && i < a.length()) ? a[i] : -Huge(i);
let y; // What do I initialize this too.
if (i <== 1 && i < a.length()) {
y = a[i]; // a side effect
} else {
y = -Huge(i); // another side effect
}
Besides, it blends well with functional programming where side effect are better avoided.
You have cheated by adding that comment noise.
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.
Fortran’s ASSOCIATE construct can help with that.
associate (x=>(complicated variable))
associate (x=>(complicated variable))
if (test) then
x = …
else
x = …
end if
end associateI thought modern Fortran had C like operators?
This is a big step for Fortran!
Well, if Fortran is going to borrow from C, to repay the favour I trust we'll get computed GOTOs in C31.
Computed GOTOs in C are just pointer arithmetic and casts.
Can you jump to a computed GOTO in C? I guess you can if you cast to a function pointer...
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.
[deleted]
Yes, but it’s a GCC extension, not standard.
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!
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
And for those wondering why IF was awkward, there was no ELSE until Fortran 77, and doing that with GOTOs was a little ugly.
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)
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.
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.
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.
Incidentally, gfortran treats the reduction like C, which seems a deficiency as the standard allows it not to.
I'm too lazy even to click and read it, but you mean stuff like:
const x = y || 3;
?
const x = y || 3;
?
[deleted]
That would be a short-circuiting logical operator.
Probably more like:
$y>5 || die "y should be greater than 5";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.
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/search?l=fortran&p=1
(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)
(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)
Similarly, scipy is 18% FORTRAN (jumpy is 0.01% so I didn’t think to link it.)
https://github.com/scipy/scipy
https://github.com/scipy/scipy
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).