Modern Fortran Quadpack

Announcements
1

I think it’s been mentioned in other posts, but I wanted to officially announce the new, Modern Fortran Quadpack library for numerical integration (quadrature):

This is a complete modernization and refactoring of the old library from Netlib. Changes include:

  • It has been converted from FORTRAN 77 fixed form to modern free form syntax. This includes elimination of all GOTOs and other obsolescent language features.

  • It is now a single stand-alone module, and has no dependencies on any other code from SLATEC or LINPACK.

  • It is a Fortran Package Manager package.

  • The separate routines in the original library for single and double precision have been eliminated. The library now exports a single (real32), double (real64) and quadruple (real128) precision interface using the same code by employing a preprocessor scheme.

  • The coefficients have been regenerated with full quadruple precision. This was done using a new program that employed the MPFUN2020 arbitrary precision Fortran library. Quad-precision versions of these routines are available in no other library that I’ve been able to find.

  • Some minor bugs have been fixed in the original code that were in there for decades (see here, here, here, and here ).

  • Other procedures not present in the original QUADPACK have been added (new routines, and modernized ones from old libraries such as SLATEC and the NSWC Library): QUAD, AVINT, QNC79, GAUSS8, SIMPSON, and LOBATTO.

  • The SLATEC docstrings have been converted to Ford style, which allows for auto-generation of the API docs.

  • Some typos, there for decades, have been corrected in the comments.

  • It’s unit-tested with GitHub Actions CI

The goal here is to restart Quadpack development where it left off 40 years ago. Bugs can be fixed, and new routines can be added. This can be the standard state-of-the-art library for numerical quadrature once again, second to no other library in any other programming language. There’s no reason to be stuck with the old Netlib FORTRAN 77 code anymore. Check the GitHub issues to see some ideas on new methods that we want to add. Join us!!

Just like MINPACK, maybe we eventually move this under the fortran-lang umbrella, and also maybe try to get it into SciPy? @certik what do you think?

See also

28 Likes
2

Thanks! I think this is great. Yes, we should move under fortran-lang. I think minpack is more ahead in terms of modernization, so we should try that first into SciPy. Then the other libraries.

4 Likes
3

Just curious re: the following:

  1. Is Modern Quadpack part of Fortran stdlib? If not, can it not be?
  2. What are the implications of inquiry 1 above?
  3. Say Modern Quadpack is further refactored to use the kinds, math constants, etc. from Fortran stdlib: prima facie, it appears a good step forward to me but are there cons about which I am unaware other than dependencies on stdlib which is growing to be quite big?
1 Like
4

It is not currently part of stdlib. I’m not sure it needs to be. With FPM, we can have a bunch of standalone libraries and you can just pull down the ones you need, no problem.

I did not use the fypp thing that stdlib is using so I could stick with standard fortran, so my IDE/linter/etc will work, which I have come to depend on. But, if you look at the code, you can see that it publishes real32, real64, and real128 versions of all the routines. So, from a user point of view, you get the same thing. And from a developer’s point of view, you have no code duplication (just a little boilerplate) and a file that editors/linters can understand as Fortran.

Also, it’s not clear if SciPy would accept an stdlib dependency. I don’t know.

Putting it under fortran-lang I think just gives it (maybe) an air of legitimacy. That’s really the only reason for that.

I agree about waiting to see if we can get Minpack in, and then go from there.

3 Likes