About a Fortran Scientific Library

Dear all,

I’m (almost) new to the forum so maybe my question is already answer elsewhere, although I couldn’t find it. If that is the point, I’ll be happy if anyone can point me to the question.

Otherwise, as newbie I’d like to ask what is,if there is, the status of creating a standardized Fortran mathematical library. As far as I could see in the web page and in the Github repo the Fortran Standard Library is intended to cover this issue, but I wonder how’s going the development and which is, if there is, the roadmap of this development. I just ask because is in this part where I like to start to contribute so I need to have an idea.

I also ask because I think that this is, in my opinion, one of the weak points of Fortran. I remember that on the Open Source podcast, when presenting this project, there was the question “why people is not choosing Fortran for new projects?”. In my opinion, and what I see around me, is that most of the people don’t want deal with the fact of having to code their own numerical routines and don’t want to search on the internet to non-documented routines while they can just write a simple Python script to solve their problems. This is funny because we all know that many Python numerical functions are no more than interfaces to Fortran code. However, it is still easier, for a person starting a new project and lazy to gather external numerical routines to just use other programming languages that easily include these routines.

For example, now I’m using the Fortran interface to the GNU Scientific Library (GSL) (written in C) from https://doku.lrz.de/display/PUBLIC/FGSL±+A+Fortran+interface+to+the+GNU+Scientific+Library which is a nice option to overcome this problem. Again, I think that some routines of the GSL are also interfaces to Fortran code, so I might be using Fortran interface to C code interfacing Fortran code :crazy_face:

What I’m aiming for is to for example have a systematic access to numerical routines as for example the LAPACK and BLAS (if the license allows it) and all other good numerical routines out there in Fortran code.

So again, what is the strategy to this point, if there is? If not, what are your thoughts, how do you think we can face this point?


Hi @iarbina, our strategy is two fold:

The second point will allow easy reuse of Fortran libraries and will see a boom of Fortran libraries online. This will then feed into the first point, of consolidating a rich standard library.

P.S. Thanks for watching our open source podcast!


At the last monthly call we touched briefly upon the “goal of Fortran”. Perhaps I can use this thread to elaborate my view further.

In fact several mature scientific libraries exist in Fortran. The most notable examples are

Unfortunately, the ones that are actively maintained (NAG, IMSL) are not open source. HSL is free for non-commercial use, but obtaining and using the code is not very user-friendly. The SLATEC and NSWC on the other hand are Fortran 77 style codes with old-fashioned calling sequences and lacking modern documentation. The GNU Scientific Library you mention was in fact developed as a modern replacement to SLATEC.

There are hundreds more of specialist packages, if you think about all the codes available on netlib and GAMS.

Since Fortran users are scientists and engineers, most of them lack the training in software engineering and web development, which are necessary to set up an accesible library. Thinking of the era of old mainframe computers, not everyone had a course in numerical analysis or even the opportunity to work with a computer. It would have made sense to pay a professional provide you with the routines needed to solve your computational problem. At the same time new programs (programming languages) such as MATLAB and Octave were developed, to give people access to numerical tools without having to learn Fortran.

Cleve Moler wrote about this in his blog:

In the 1970s and early 1980s, while I was working on the LINPACK and EISPACK projects that I discussed in two previous posts, I was a Professor of Mathematics and then of Computer Science at the University of New Mexico in Albuquerque. I was teaching courses in Linear Algebra and Numerical Analysis. I wanted my students to have easy access to LINPACK and EISPACK without writing Fortran programs. By “easy access” I meant not going through the remote batch processing and the repeated edit-compile-link-load-execute process that was ordinarily required on the campus central mainframe computer.

(Thanks to @urbanjost, we still have a copy of an old version of MATLAB.)

A similar motivation can be found from the Octave developers:

Octave was originally conceived (in about 1988) to be companion software for an undergraduate-level textbook on chemical reactor design being written by James B. Rawlings of the University of Wisconsin-Madison and John G. Ekerdt of the University of Texas. We originally envisioned some very specialized tools for the solution of chemical reactor design problems. Later, after seeing the limitations of that approach, we opted to attempt to build a much more flexible tool.

There were still some people who said that we should just be using Fortran instead, because it is the computer language of engineering, but every time we had tried that, the students spent far too much time trying to figure out why their Fortran code failed and not enough time learning about chemical engineering. We believed that with an interactive environment like Octave, most students would be able to pick up the basics quickly, and begin using it confidently in just a few hours.

We could say that at this point Fortran was already losing users. For simple scientific calculations, interactive usage is much more straightforward than the Fortran development cycle. Thinking of F77, without modules, and without a good packaging solution, it is painstaking process to get all your calls correct. Especially, when you are doing all your work through a tiny terminal.

So at this point we could say Fortran was already becoming a niche language for HPC users, and falling out of favor for data analysis and everyday scientific calculations. One of the places were Fortran was in everyday use for statistics, data analysis, and plotting, was at CERN in the form of the the CERN Program Library. This was until it was finally superseded by ROOT (a program in C++) in 2003.

Concerning strategy, on top of what @certik wrote, with respect to stdlib, I think it is most important we define interfaces for the common scientific procedures we would like to see (essentially the stuff in NAG and IMSL).

Then it is just a matter of time to consolidate and refactor the publicly available Fortran codes which fit into such a scientific library (the Fortran codes which are wrapped in SciPy, SLATEC, other codes from netlib, etc.). This would be the free stdlib.

I used the word refactor, because I have the experience that it can be easier to generate a robust Fortran wrapper in Python, than it is to provide the same old Fortran package in modern Fortran. This is because Fortran, compared to Python, lacks assertions, exception handling, positional and keyword arguments, introspection, etc. Ironically, the old F77 style interfaces with explicit length array arguments and work arrays are easier to wrap, than some modern Fortran codes that utilize allocatable and assumed shape arrays, derived types, etc.

If we can bring stdlib far enough ahead, hopefully then organizations such as Intel, NAG, and IMSL would decide to offer versions of their own routine libraries, conforming to the stdlib interface. This can be done very elegantly using sub-modules. In fact we could even take a shortcut, and have back ends based upon GSL or Boost C++ libraries.

But agreeing upon on a sensible Fortran library API is the first and most crucial step.


Fortran has keyword arguments.

1 Like

My mistake. What I had in mind, was the Python way of receiving formal parameters **kwargs that becomes a dictionary.

Thanks a lot for the replies! Sorry I didn’t arrived to the ‘monthly call’ where you kind of address this point. Although not very deeply.

So, my concern about @certik first point is more like ‘What does “Make progress” really means?’

Thanks @ivanpribec for your nice and detailed reply. So, that’s what I was thinking to be one of the solutions, define interfaces from these already available code, the one in netlib for example.

On the other hand, another concern would be to rely on proprietary libraries and their kindness to share their work…

Liked the possible shortcut to have back ends based upon GSL, although that’ll be pretty much similar to that Fortran interface to GSL I mentioned before.

Maybe moving to another topic, what did you mean @ivanpribec with free stdlib? Is there any idea to have non-free parts of stdlib? For example, I have no much trouble on finding the code and create my library for my code, but sometime the issue is when I want to share with other people. Then I might have the problem of proprietary software or that people I share my code with has trouble with the non-standardized library.

P.S. I’m sorry because I know I’m pretty much obsessed with this point.

I meant simply the open-source version. What I had in mind was kind of how you have the standard NumPy, Scipy libraries, and then you have the Intel Distribution for Python which uses the specialized Intel libraries under the hood. The former are available to everyone, the latter only to those with access to Intel products. (Although I think MKL is available to everyone nowadays).

To be more specific, say we want to have a Fortran interface for cubic splines. We can write a new implementation like they did in SciPy (see CubicSpline). Or we can base our implementation upon pchip, or the pppack code by Carl de Boor.

On the other hand Intel could decide to use the data fitting functions from Intel MKL as the back end. IMSL could role out their version based on their spline_fitting routines. And so on.

1 Like

@iarbina please join us at the next Fortran call and we can discuss it more.

Progress means making stdlib usable like SciPy, and use it as a dependency with fpm or directly. If you have any questions or concerns, let’s discuss more.

1 Like

Ah, ok, I see. Yeah, of course I guess vendors will still create and own their libraries.

Yeah, that’s what I meant by roadmap, to discuss whether to create new code or interface older one. Which, for me, seems more realistic to interface older one, at least for things as special functions.

@certik That, of course, sounds great.

I see that probably there’s still too soon to discuss things like the ones mentioned by @ivanpribec and how to approach the creation of a mathematical/scientific library until other essential parts of the stdlib are developed.