Fortran adds conditional expressions | Hacker News Reader

Fortran adds conditional expressions

j3-fortran.org

158 pointsBostonian77 comments

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/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)

Similarly, scipy is 18% FORTRAN (jumpy is 0.01% so I didn’t think to link it.)

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).

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

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.

I'm too lazy even to click and read it, but you mean stuff like:

const x = y || 3;

Probably more like:

  $y>5 || die "y should be greater than 5";

That would be a short-circuiting logical operator.

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.

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.

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!

Sample syntax:

    y = ( i>=1 .And. i<=Size(a) ? a(i) : -Huge(y) )

The proposal has been approved, but the final standard will be voted on, and it will take time for it to appear in compilers.

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))

but this is risky, because merge does not short-circuit, and the program could crash if i < 1. The ternary syntax

    y = (boolean ? expression_1 : expression_2)

only evaluates one of the expressions.

"I don't know what the programming language of the year 2000 will look like, but I know it will be called FORTRAN." -- C.A.R. Hoare

The better one of his, which I've probably posted before, is "ALGOL 60 is alive and well and living in FORTRAN [sic] 90."

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.

https://gcc.gnu.org/onlinedocs/gcc/Labels-as-Values.html

Yes, but it’s a GCC extension, not standard.

I remember the comp.compilers moderator calling C a Fortran-like language.

Well, that's a joke referring to the typical Computer Science jargon of calling them both Algol-like languages.

I don't recall him saying that while I used to read that group, but I would have chuckled.

The ternary operator is something I miss when using Go

If as an expression is something I miss almost everywhere. Trenary has always seemed like an afterthought.

Kotlin doesn't have a ternary operator, although `if` is an expression, I still miss it though.

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.

I thought modern Fortran had C like operators?

how do people currently write conditional statements?

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 if

This 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:

    const y = (i <== 1 && i < a.length()) ? a[i] : -Huge(i);

than:

    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
    }

And you end up with a mutable variable that might change later on (true only for language with mutable/non mutable variable of course).

Besides, it blends well with functional programming where side effect are better avoided.

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))

  if (test) then

   x = …

  else

   x = …

  end if 

 end associate

You have cheated by adding that comment noise.

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.

This is a big step for Fortran!

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.

to be honest, this was just a very stupid joke. i guess there is no good reason to compare the two.

Jokes are difficult to pull off well on HN. Worst downvotes I ever get are when I'm joking.

The trick is to lay it on so heavily that there is no joke anymore.

Sadly, yes.

(^_^)

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.

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.

Im quite happy with my new apartment and also will not be needing fortran

I just moved to the apartment upstairs because it has a familiar floor-plan, is renovated, and has a slightly better view.

Ok cool but is React+Js really a competitor to Fortran…?

Both are Turing complete, so it is the case

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.

I don't know why people still bother using Fortran, Magic the Gathering obsoleted it decades ago.

Reply on news.ycombinator.com