Fortran: An ideal language for writing "Templates" of numerical algorithms (?)

[everythingfunctional]

@certik

what about g(1, f(x), 3) would it be equivalent to g(1, a, b, 3) ?

I think that would be reasonable. Maybe there are some other edge cases I’m not yet seeing though.

@certik

If so, then we have essentially invented the *args syntax from Python

Does that seem so bad? If it makes the code look more like the math I think that’s a good thing and exactly what we should be striving for. If we can make it easier for scientists and engineers to write code that looks like what they wrote on their white boards, that’s a huge win.

[certik]

So essentially it behaves like a tuple in Python, but it’s never actually a tuple, you can only see the results of a tuple operation. Using Python:

t = f(a, b)
x, y, z = t

We cannot do these two lines individually, we can only do:

x, y, z = f(a, b)

This avoids adding a whole new type to Fortran, and always treating the “tuple” as separate entities, separate return variables from a function.

[everythingfunctional]

I think that would serve a lot of use cases and not introduce any runtime penalty. Of course, any time I’ve asked the committee for syntactic sugar so far, it has flopped, but maybe if we prototype it and convince other compiler writers of its usefulness it could work?

[Beliavsky]

@certik

Yes, that’s doable. But there are other issues, what about g(1, f(x), 3) would it be equivalent to g(1, a, b, 3)? If so, then we have essentially invented the *args syntax from Python.

I don’t think Fortran should add this. Suppose there is a function call

g(a, f1(x), b, f2(x), c)

Currently you know that c is the 5th argument of g, and you can check the definition of g to set c appropriately. If f1(x) and f2(x) can return tuples, you don’t know what argument c corresponds to unless you also look at the definitions of functions f1 and f2. Such code would be difficult to understand.

[certik]

@Beliavsky

Suppose there is a function call

g(a, f1(x), b, f2(x), c)

Currently you know that c is the 5th argument of g , and you can check the definition of g to set c appropriately. If f1(x) and f2(x) can return tuples, you don’t know what argument c corresponds to unless you also look at the definitions of functions f1 and f2 . Such code would be difficult to understand.

Exactly. My worry also.

I would simply not allow functions that return more than one variable in expressions.

[Beliavsky]

@zaikunzhang

Fortran has cons, of course.

1. One of the features that I dream about the most is for Fortran to support functions with multiple outputs. If Fortran had such capability, then the code would be more readable and more faithfully correspond to the math formulations. Of course, multi-output functions can be implemented as subroutines, but that is normally not how we formulate the functions mathematically — recall that we want the code to be as similar as possible to the math formulations. Another possibility is to return a structure, but it is again likely to differ from how we write the functions in mathematics — much more often than not.

Could Fortran allow a tuple to be set to the components of a derived type, so that the commented line in the code below would be valid? Then a function that returned a derived type could be accessed as if it returned a tuple.

module m
type, public :: dt
   integer :: a,b
end type dt
end module m

program main
use m
type(dt) :: x
integer  :: a,b
x = dt(3,4)
! a, b = x ! equivalent to lines below
a = x%a
b = x%b
end program main

There is a precedent for this kind of behavior. You can write
print*,x

instead of

print*,x%a, x%b

The compiler “unwraps” the derived type for you.

[zaikunzhang]

@Beliavsky

In Matlab, can the results be named in the function call, so that if the function defines outputs c1 and c2, one can write

[c1=a1, c2=a2] = f(x)

As far as I know today, MATLAB does not support named arguments.

[Beliavsky]

@certik

@Beliavsky

Suppose there is a function call

g(a, f1(x), b, f2(x), c)

Currently you know that c is the 5th argument of g , and you can check the definition of g to set c appropriately. If f1(x) and f2(x) can return tuples, you don’t know what argument c corresponds to unless you also look at the definitions of functions f1 and f2 . Such code would be difficult to understand.

Exactly. My worry also.

I would simply not allow functions that return more than one variable in expressions.

Maybe it could work if keyword arguments are mandated for the first tuple and all remaining arguments. Currently you need to use keyword arguments for the first non-positional argument and all remaining arguments. So if function g has 7 arguments c1 to c7, you could write

g(a,(c2,c3)=f1(x),c4=b,(c5,c6)=f2(x),c7=c)

[zaikunzhang]

Hi, @everythingfunctional , nice to get your comments!

@everythingfunctional

First, I’m glad you liked the blog post. And your project sounds interesting and commendable. I’m excited to see how it goes.

Your blog is definitely insightful and illuminating. I completely agree with the opinions inside. Indeed, I have forwarded your blog to a student of mine and convinced him to rewrite his code (partially) to align with the principles stressed in your blog.

(Here is the link again to the blog if others are interested: Communicating with Whom?. The link in my original post was broken and now fixed.)

As well elaborated in your blog, I wish literally everyone who codes nowadays realizes that she/he is communicating with not only machines but also humans, and that coding is not only to get some job done by machines but also to document human knowledge.

For this reason, I believe that it is very often not a bad idea to compromise performance/efficiency for clearness/readability/naturality. We need to keep in mind that computing power is increasing and will continue to increase in the foreseeable future. As a computational mathematician, I do understand the importance of performance/efficiency in algorithms/coding. However, any useful technique that truly improves performance/efficiency should be abstracted, standardized, encapsulated, and modularized so that it can be easily pulled out and plugged into programs, rather than spread in the code as tricks. “Tricks” that sacrifice clearness/readability/naturality may (quickly) become pointless with more powerful machines, but we cannot expect that mankind can magically become good at handling code of poor clearness/readability/naturality in a few years. Machines evolve much faster than humans. We should rely on the evolution of the former rather than the latter.

For the same reason, I also require myself not to write code that relies heavily on special features of programming languages unless those features are natural in human languages. When my student, who is a Python enthusiast, tells me that “Python has this great feature that does not exist in any other language, and it enables us to shorten the code a lot”, I am always skeptical and tell him not to rely too much on particular features of languages (even though I do not always succeed).

Talking about documenting human knowledge, we need a language that is as similar as possible to human languages (in a broad sense, mathematics is one of them), or, as mentioned in your reply, a language that enables us to code as if we communicate with a human on a blackboard. Fortran, thankfully, was invented to be such a language and has kept evolving towards this direction. I wish that the Fortran community always keep in mind that Fortran means “Formula Translator” when deciding whether a feature should be introduced into the language or not.

@everythingfunctional

How do you write a function with multiple outputs on the blackboard? Is it a, b = f(x) , or something else?

According to my experience at math departments for almost 20 years, people would write

(a, b) = f(x)

or

[a, b] = f(x),

similar to MATLAB. Of course, this is not true if a and b are two components of a single mathematical object C that has a natural definition. In that scenario, a well-trained mathematician should write

C = f(x)

rather than naming the components of C unless necessary; the best way to code this f is then a function outputing a structure/derived type, but again, the definition of C must be natural and it should not be several pieces that are sewn together cumbersomely.

Thank you again!

[everythingfunctional]

@Beliavsky

g(a,(c2,c3)=f1(x),c4=b,(c5,c6)=f2(x),c7=c)

This seems the natural extension to keyword arguments. I’d be in favor of allowing it. I’m not sure it needs to be mandated, but highly recommended in cases where there is a possibility of reader confusion. It would also allow for interesting, if possibly contrived use cases like

z = h((c1, c3) = f(x), (c2, c4) = g(y))

[lmiq]

I think Fortran is a great language for the project, particularly if the goal is to provide a series of functions to be assembled by high level code (i. e. from Python, R, Matlab), into algorithms.

But if you have to choose a high level language to code the algorithms themselves side by side with the Fortran implementation, take a serious look at Julia. Julia is not statically typed nor has intents. But the other properties it has, in particular the mathematical notation (better than any language I’m aware of) and the actual functionality, meaning that the code will be actually performant and useful, as will be the Fortran one, for composability. (a Python implementation of an algorithm won’t probably be much more useful than the pseudo code).

Here I have a comparison of Julia and Fortran syntaxes: 2021_FortranCon/benchmark_vs_fortran at main · m3g/2021_FortranCon · GitHub.

[zaikunzhang]

Hi @imiq! Thank you for the suggestion. I will surely check Julia.

Visiting the page you linked, I am particularly amused by the fact that you can even use “Δ” in variable names. That’s very impressive!

[zaikunzhang]

Indeed, what we are looking for is a lingua franca for numerical computation — a language that is simple, straightforward, and strict. Fortran was deemed in that way, but evolution is needed for it to continue to be regarded as such. See posts by @FortranFan under Fortran returns to top 20 TIOBE index, Eliminate implicit mapping, and Fortran and Neural Networks.