Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Add QUADPACK to fpm registry #43

Open
dhermes opened this issue May 16, 2021 · 51 comments
Open

Add QUADPACK to fpm registry #43

dhermes opened this issue May 16, 2021 · 51 comments

Comments

@dhermes
Copy link

dhermes commented May 16, 2021 •
edited
Loading

I actually would be willing to do all of the work here but am not sure where to start.

AFAICT the original source has been converted to Fortran 90 by John Burkardt (single and double precision). The big concerns then are (A) LICENSE, this is the biggest (B) build tooling e.g. Make or CMake, not sure what fpm prefers (C) documentation.
@ivan-pi
Copy link
Member

ivan-pi commented May 16, 2021 •
edited
Loading

QUADPACK was included in SLATEC and is thereby in public domain (at least in the USA). See this comment from the Scipy repository. The website from Leuven University also mentions QUADPACK is included in Octave and that C translations are available in GSL. So open source usage seems to be permitted.

The version of QUADPACK included in SciPy has some fixes, like replacing calls to linpack routines with their respective lapack equivalents. Personally, I would prefer to use the Scipy version over those of Burkardt. The Intel Fortran compiler could be used to automatically generate the missing interfaces, and leave the source as F77 code. The automatically generated interfaces could then be manually compared to the documentation and published listings to get the intent attributes correct.

Concerning build tools, the idea of the fpm registry is to collect fpm compatible packages. The best approach is to allow fpm to do the building, no make or cmake is required. One hurdle will be how to provide both single and double precision versions. Edit: probably the single precision versions should be downloaded from netlib and prepended with s. Then the single and double precision versions can be placed under a generic interface. It will be necessary to cross-check against the SciPy modifications to bring the single precision versions up to date.

Currently, fpm offers no tools to automate documentation. Most fortran-lang projects are using FORD and GitHub actions to automate the site generation. Personally, I find FORD to be quirky. For the QUADPACK documentation it might be possible to extract the comments from the source files (either the SciPy or SLATEC versions) using a Python/Perl script and generate restructured text for some other documentation website generator (Sphinx, MkDocs, ...).

@certik
Copy link
Member

certik commented May 16, 2021

We could consider using the quadpack from SciPy. That way we are fine with the license, we'll have the fixes and it can also be useful from the point of view of SciPy and other such libraries to eventually use the quadpack fpm package.

Also, I would recommend to maintain this under the fortran-lang github organization. Many of the issues facing here are identical to fftpack: #40, see the discussion there.

Let's figure out a good approach to these things.

@dhermes
Copy link
Author

dhermes commented May 16, 2021

RE: SciPy source, the files in https://github.com/scipy/scipy/tree/v1.6.3/scipy/integrate/quadpack are all Fortran 77. The merits of the Burkardt code is that it is in Fortan 90, making it accessible to a wider set of compilers (e.g. lfortran). I am very open here on where the source comes from and I would say NOT very educated on historical forks since the original QUADPACK in 1981, just trying to see if there is something stable AND quasi-modern.

@certik
Copy link
Member

certik commented May 16, 2021

Good point. The only reason I suggested SciPy is that I know they maintain it and fix bugs and the code should be correct and working. If we use some older unmaintained version, it might have bugs. Aren't there tools to convert fixed form to free form? We could start with the SciPy version, convert to free form, add to modules, etc.

P.S. LFortran will eventually have a parser for fixed form also (https://gitlab.com/lfortran/lfortran/-/issues/82).

@awvwgk
Copy link
Member

awvwgk commented May 16, 2021

I added a couple of formatters to the package index a while ago.

I made good experience with findent, which is primary targeted to parse legacy Fortran and handle dozens of non-standard extensions (packaged on conda-forge here). Camfort and fortran-src also have legacy Fortran parsers and there is fpt from the last monthly call.

So plenty of tools for the job out there, but most important is to have tests to verify the converted code against the original one.

@ivan-pi ivan-pi changed the title Add QUADPACK to fpm regsitry Add QUADPACK to fpm registry May 16, 2021
@ivan-pi
Copy link
Member

ivan-pi commented May 16, 2021 •
edited
Loading

Good point. The only reason I suggested SciPy is that I know they maintain it and fix bugs and the code should be correct and working. If we use some older unmaintained version, it might have bugs.

Not sure if we can call it maintenance. The code has been untouched for the last 3 years and there are some open bug tickets however, only one seems to be an actual numerical issue, the rest look like compiler and build setup issues.

The SciPy version of QUADPACK would also benefit from some refactoring (see scipy/scipy#4455, great issue title!). The QUADPACK routines make use of the following three machine constants:

  1. machine epsilon (d1mach(4))
  2. the largest non-overflowing positive real number (d1mach(2))
  3. the smallest non-underflowing positive real number (d1mach(1))

which are currently retrieved using the d1mach() function (a description can be found in the SLATEC documentation or BLAS faqs). The version used in SciPy looks like it is taken from Netlib, but from some third package (not SLATEC or QUADPACK). In the meantime (30 years ago...) Fortran 90 added intrinsic functions to retrieve these constants directly using intrinsic functions. I am aware of a few different refactored versions of d1mach:

Interestingly, the SciPy d1mach source has a commented out C implementation:

C implementation 
 /* Standard C source for D1MACH -- remove the * in column 1 */
#include <stdio.h>
#include <float.h>
#include <math.h>
double d1mach_(long *i)
{
	switch(*i){
	  case 1: return DBL_MIN;
	  case 2: return DBL_MAX;
	  case 3: return DBL_EPSILON/FLT_RADIX;
	  case 4: return DBL_EPSILON;
	  case 5: return log10((double)FLT_RADIX);
	  }
	fprintf(stderr, "invalid argument: d1mach(%ld)\n", *i);
	exit(1); return 0; /* some compilers demand return values */
}

@LKedward
Copy link
Member

Note that Carlos @brocolis already has an fpm package for the original quadpack here which also includes an f90 interface module.

@certik
Copy link
Member

certik commented May 17, 2021

Note that Carlos @brocolis already has an fpm package for the original quadpack here which also includes an f90 interface module.

That's exactly what I had in mind! @brocolis would you be interested in moving the package under fortran-lang so that we can maintain it as a community?

@zoziha zoziha mentioned this issue May 17, 2021
Closed
@ghost
Copy link

ghost commented May 18, 2021

Yes. Someone with appropriate permissions could move it to fortran-lang.

@ghost
Copy link

ghost commented May 26, 2021

My original plan was to write an higher level function quad on top of QUADPACK, but since I read the GNU Octave implementation for quad, I believe I cannot re-implement it myself under a different license. However, I would be happy to transfer the repository to fortran-lang as it is now.

@certik certik mentioned this issue May 26, 2021
Open
@ivan-pi
Copy link
Member

ivan-pi commented May 26, 2021

The scipy.integrate.quad has a very similar interface to the Octave quad. The SciPy version is under a BSD-3 license.

But I would suggest we do it jointly under the fortran-lang repository.

@ivan-pi
Copy link
Member

ivan-pi commented May 26, 2021

However, I would be happy to transfer the repository to fortran-lang as it is now.

I think if you follow the instructions on transferring repositories you could transfer to @milancurcic, and he could put it under the fortran-lang organization.

The other option would be to simply clone the repository, and push it into a new fortran-lang repository (not forking it).

@awvwgk
Copy link
Member

awvwgk commented May 26, 2021 •
edited
Loading

Repository transfers (and creation) can currently only be handled by @certik, @milancurcic and @LKedward, either by temporarily raising member privileges or by a two step transfer. I don't think we have yet established a workflow for this process.

@certik
Copy link
Member

certik commented May 26, 2021

@LKedward, @milancurcic I would be interested in your feedback on maintaining this under fortran-lang.

@LKedward
Copy link
Member

@LKedward, @milancurcic I would be interested in your feedback on maintaining this under fortran-lang.

I have no fundamental objections to moving this and other legacy packages to fortran-lang as long as we have one or more persons identified to spearhead the initial modernisation and maintenance required to bring the packages up to standard. (Which it looks like we do here!) In particular, we should strive to maintain a high quality of packages maintained under fortran-lang which I will clarify by quoting from our extra 'recommend criteria' in the package index guidance:

  • Documentation: any form of written documentation aimed at users of the package. Ideally this should cover:
    • Supported / tested compilers, dependencies, build and install process, modules contained within the package, procedures made available and their interfaces, example code
  • Contributing: details on how users may submit issues and contribute to the development of the package
  • Tests: any form of executable test(s) that can be used to verify the functionality of the package
  • Portability: no non-standard language extensions or proprietary dependencies
  • fpm: support installation by the Fortran Package Manager fpm

@awvwgk
Copy link
Member

awvwgk commented May 27, 2021

Do we know of any users of QUADPACK, who are interested in devendoring their version in favor of a @fortran-lang one? Is anyone involved in this thread using QUADPACK in a production code and willing to offer their code base for testing?

I'm also wondering about the QUADPACK license, is it public domain since it is part of SLATEC? How would we handle and license contributions to this project?

@arjenmarkus
Copy link
Member

arjenmarkus commented May 27, 2021 via email

@ivan-pi
Copy link
Member

ivan-pi commented May 27, 2021

Is anyone involved in this thread using QUADPACK in a production code and willing to offer their code base for testing?

Well there are the possibly thousands of users using it via SciPy and Octave. Also the NAG quadrature routines are based upon QUADPACK. Also the IMSL library seems to be based off QUADPACK. Several papers discussing QUADPACK (with some tests) can also be found in

Keast, P., & Fairweather, G. (Eds.). (1987). Numerical integration: recent developments, software and applications. https://doi.org/10.1007/978-94-009-3889-2

SciPy has a set of tests for QUADPACK that can be adapted: test_quadpack.py.

The QUADPACK book (https://link.springer.com/book/10.1007%2F978-3-642-61786-7) contains error plots of 17 test integrals. There are also 10 demonstration programs. I would suggest to add these as the original tests.

@certik
Copy link
Member

certik commented May 27, 2021

SciPy is the most obvious one. Yes, some of the SciPy maintainers are open to the idea of using fortran-lang's version, but of course it would depend on the details. I have not seen any objections like "absolutely not". So that means we should do our best, and if we do, there is a good chance of SciPy using it, one way or another.

@arjenmarkus
Copy link
Member

arjenmarkus commented May 27, 2021 via email

@certik
Copy link
Member

certik commented May 27, 2021 •
edited
Loading

So the next step, as @LKedward said, is to find a person who would be willing to take the lead on this. @dhermes and @brocolis, would you have time for that? The aim should be to maintaining this as a community, under fortran-lang. But it's good if at least initially there is one or two people who push the community to get it done, i.e., takes the lead on this.

One possible path forward is:

  • Take the repository https://github.com/brocolis/quadpack by @brocolis.
  • Figure out the license situation. If in doubt, we might want to just take the version from SciPy, which is under BSD license.
  • Move it under fortran-lang.
  • Improve the tests, per @ivan-pi's pointers
  • Improve documentation
  • Apply any fixes

What should be the long term goal? Should we include integration routines that we develop, such as by @arjenmarkus as indicated above? I would suggest to define what the long term objective is. I feel we should probably just "maintain it", i.e. ensure it compiles without warnings with all Fortran compilers, fix any bugs if they are discovered, and maintain modern Fortran and C API to it. But other than that, I think new algorithms should go into a new/separate fpm package. What do you think?

@jacobwilliams
Copy link
Member

jacobwilliams commented May 27, 2021 •
edited
Loading

I would highly recommend not moving F77 code to fortran-lang. Or wrapping F77 with a modern interface. I think that is a bad idea. We need to modernize the code to show what can be done with modern Fortran. There is a lot of room for improvement in quadpack. We don't want to be stuck with the old F77 code like some sort of new netlib. Convert it to free-form and then go from there.

EDIT: For example, here's some modernized SLATEC integration code: https://github.com/jacobwilliams/quadrature-fortran

@certik
Copy link
Member

certik commented May 27, 2021 •
edited
Loading

I think we should discuss this at the next Fortran call.

@jacobwilliams I think we all agree that we want modern Fortran implementations of these basic algorithms, whether as standalone packages and/or part of stdlib. Many of such packages could be maintained under fortran-lang also.

The main problem that we are trying to solve in this thread is that codes depend on these old packages (fftpack, odepack, minpack, quadpack, ...) so having a maintained version helps. Also to compare against the "modern" packages, to ensure that they are actually better, or at least as good, i.e., did not regress on speed, accuracy or "simple API" (subjective).

The question is whether the modernized version should be part of the same package, replacing the old code (I think that is what you are suggesting?), or a separate package.

I think as long as performance and the API can be kept exactly the same, it is fine to be part of the same package. If the API changes, then I think it should probably be a separate package.

As another example, I took fftpack and modernized it here:

https://github.com/certik/hfsolver/blob/b4c50c1979fb7e468b1852b144ba756f5a51788d/src/fourier.f90#L201

Things to keep in mind when modernizing:

  • performance: did it get slower? To answer it, I think we want to have the original package, easy to install, to compare against
  • accuracy: is it as accurate?
  • API: is the new API easier to use?

I have benchmarked my new "modern Fortran" fft implementation, and on the one benchmark I used (about million element 1D fft), it was about the same. But later I realized that for smaller fft, such as 128 (which is used for 3D 128^3, very common in electronic structure calculations), it might be slower. Based on my experience, I think it is actually really hard to ensure the new code is as fast.

For all these reasons, I think it would be valuable to "conserve" or "preserve" these old libraries, and only do changes that keep performance, accuracy and API. Moving from fixed to free form is fine I think. Keeping the performance is tough, for that we need good benchmarks, or not change the code significantly. Keeping the API is simple (we just need tests), but that does not allow to modernize the API.

@ivan-pi
Copy link
Member

ivan-pi commented May 27, 2021

I must say the book by Keast en Fairweather is a bit expensive (200 euros for the e-book version). The other one a bit less so.

For the time-being, I have access to digital versions of both books through a university subscription. I am happy to extract the tests from the books.

One problem with modifying the API is that old codes that already use QUADPACK will require refactoring to use our "maintained" version. I think this is not constructive. Any older codes should continue to work, with the minor exception that we ask programmers to add a use quadpack, only: ... statement.

My personal goals for the modernization would include:

  1. Provide an interface module (already done by @brocolis)
  2. Provide the missing tests, build tools, and online documentation
  3. Refactor the original sources to free form, removing any obsolescent language constructs, and following any modern computational/software practices.

Performing step 3 after adding tests, helps guarantee accuracy and performance are preserved. The results and timings of the tests, should be preserved as build artefacts.

Only after these steps are complete would I be in favor of adding new routines with simplified API's (through use of optional arguments, or derived types).

@arjenmarkus
Copy link
Member

arjenmarkus commented May 28, 2021 via email

@jacobwilliams
Copy link
Member

We need to modernize the API. We can't hold up something that requires you to stuff your problem data into iwork and rwork arrays as any kind of modern way to write code. This does great damage to Fortran anytime anyone sees code like this. It's just a fact. If somebody wants to use the old F77 code and never wants to change anything, that's fine, but those people should not be holding back progress (they have held back progress for decades now... it's time to move on). Make a modernized version, and let people see that it is better and they should use it, and if somebody is still using the old one they have an incentive to use the new one because it is better.

@certik
Copy link
Member

certik commented May 29, 2021

@jacobwilliams, we all agree that we want to use modern API to these legacy libraries. That is not a question.

The question is how to get there. You said not to move the "F77 code to fortran-lang." You also suggested to rather work on a modern Fortran replacement, a "modernized version", and it is my understanding that you do not want to use the legacy code at all, but rewrite from scratch?

I think from a practical perspective, I want to have these legacy libraries maintained, because people use them. And I would like to be able to use them at least for performance and accuracy comparison against a "modernized version" that you propose.

To conclude, are you against the plan here: #43 (comment) ?

That plan still allows to have a separate library, written from scratch, in modern Fortran.

@awvwgk
Copy link
Member

awvwgk commented May 30, 2021

If the association of @fortran-lang with the legacy QUADPACK is a blocking issue here, than I might have a suggestion to move this forward. https://github.com/quadpack is currently free, I suggest we claim the @quadpack namespace by creating a new open-source organization and move the legacy version there. This allows to cooperatively develop the QUADPACK under a neutral namespace and once we have reached a point were we want to associate our quadpack-ng with @fortran-lang we can move it here.

I personally use this strategy a lot for my projects, once they mature I tend to move them into separate organization (see @toml-f or @dftd4), since it allows me to separate the stable version from my development branches in a fork and also gives a nice namespace to include additional example packages as well.

@jacobwilliams
Copy link
Member

I absolutely support using the legacy code. There's no need to rewrite it from scratch. All I was warning against was being locked into the old api or coding style forever just to make sure that it could be used by somebody who refuses to make even the smallest modifications to their code to use it.

Consider how I made a modernized version of some these spline interpolation routines: https://github.com/jacobwilliams/bspline-fortran

At its core, are routines from CMLIB and SLATEC. I didn't have to rewrite them from scratch, but they have been changed. I had to change them in order to make the interfaces more modern, allow them to be reentrant, add features that weren't present in the original code, etc. At no point did I worry about keeping the old interface. Note that there are even two interfaces, an object oriented one (that I use), but also a subroutine one that is closer (but not identical) to the old interfaces.

So like all these sorts of codes my advice is:

  • convert fixed to free form.
  • put them in a module or modules
  • remove obsolete features: goto, common, data, iwork(), rwork(), etc.

Then you can start expanding beyond what the old codes had (maybe adding new algorithms, maybe an object-oriented interface if it makes sense, etc.)

@certik
Copy link
Member

certik commented May 31, 2021

@jacobwilliams perfect! I think the actual plan you just wrote is identical to #43 (comment), isn't it?

The only technical issue left is "put them in a module or modules", which I would very much prefer, but I don't know if this can cause issues in existing codes like SciPy. But we can help them move over to modules.

@jacobwilliams would you be against moving quadpack under fortran-lang, and we would do this work there?

What @awvwgk suggested above (quadpack organization) also works, but remember that there are tons of other libraries in the same category (fftpack, minpack, odepack, etc.), so we could create fortran-lang-legacy organization and put it there, but we might as well just put it under fortran-lang.

@jacobwilliams
Copy link
Member

I'm all for it! As long as the goal is to modernize, and not keep them frozen in amber like they are in netlib. :)

Definitely think getting SciPy used to modern fortran should also be a major goal! It is inevitable that they are going to get rid of all that Fortran 77 code that nobody wants to work on. The only question is can we offer up modern alternatives, or are they going to replace it with C/C++. I hope it will be the former.

I would also suggest avoiding the term "legacy"... Is the intent to have a namespace to work on projects that are big libraries that are outside of stdlib? I guess I'm not sure where to draw the line of separate libs vs adding them to stdlib.

@certik
Copy link
Member

certik commented May 31, 2021 •
edited
Loading

Good point. I would like to "rejuvenate" these libraries, so they are no more "legacy". Thus fortran-lang.

Regarding stdlib or not --- these libraries are well established, so should live outside. As we modernize them or even do a rewrite as a separate library, we can also think how it should be included in stdlib. I don't know yet if stdlib has to be strictly without dependencies, or if it can have dependencies (in which case just depending on these libraries might be a way).

@jacobwilliams
Copy link
Member

I think as fpm becomes ubiquitous, it won't even matter so much where a library comes from, it will "just work"!

@arjenmarkus
Copy link
Member

arjenmarkus commented Jun 1, 2021 via email

@certik
Copy link
Member

certik commented Jun 16, 2021

So we discussed this at the last Fortran call (https://fortran-lang.discourse.group/t/fortran-monthly-call-june-2021/1334) and it seems there were no objections to start to maintain these packages under fortran-lang. We also agreed to keep the original API, but add optional modern Fortran API as appropriate, and that we will figure out some of the other details as we go.

@milancurcic, @LKedward you were not at the call, are you both ok with doing that also?

@LKedward
Copy link
Member

Thanks @certik that sounds good to me

@milancurcic
Copy link
Member

I apologize for dragging this further, but I'd like to review the discussion in the call recording and get back to you later today. Overall the plan sounds good to me, but I will have a few questions.

@awvwgk
Copy link
Member

awvwgk commented Jun 16, 2021

For the concrete case of QUADPACK I have a couple of questions.

  1. From which source is this project going to start exactly?
    (https://github.com/brocolis/quadpack, https://github.com/scipy/scipy/tree/v1.6.3/scipy/integrate/quadpack, http://www.netlib.org/quadpack/, ...)
  2. Which license will changes be contributed under?
    For public domain we might have to require contributors to explicitly disclaim their copyright
  3. Who is going to lead the project?
    @dhermes extended an offer, also @brocolis offered their version as well, maybe they are still interested
    (BTW, we should really invite them into the @fortran-lang organization)

@certik
Copy link
Member

certik commented Jun 16, 2021 •
edited
Loading

Let's wait for @milancurcic to approve, then we can choose either @dhermes or @brocolis (or both) to lead the effort and resolve the questions that @awvwgk posted.

@ivan-pi
Copy link
Member

ivan-pi commented Jun 16, 2021 •
edited
Loading

I just noticed @nshaffer (member of fortran-lang) has also previously started an effort to provide a modern QUADPACK package: https://github.com/nshaffer/modern_quadpack

@nshaffer, would you be able to give your thoughts on this thread?

I also just found two re-implementations of the QUADPACK algorithms in C and C++:

@milancurcic
Copy link
Member

I agree, let's do it. My questions and comments are:

  1. Is there a quadpack repo that @dhermes and @brocolis agree to start from together? I think that would be ideal.
  2. Regarding license, I think the initial content can remain public domain and the additions and changes can be MIT. Does anyone know enough about this to confirm?
  3. We should have some criteria to decide which repos should be maintained under fortran-lang, like having dedicated maintainers, the library is high impact / common dependency, etc. This may have been discussed already.
  4. Related to 3., are there already any fpm packages that depend on quadpack? This could be a proof of need.

@certik
Copy link
Member

certik commented Jun 17, 2021

Thanks Milan.

@brocolis, @dhermes would one of you (or both!) be willing to take a lead on this?

This first thing to figure out is which repository to use and the license situation.

@ghost
Copy link

ghost commented Jun 20, 2021

I currently can't commit many hours to this project. However if we move in small steps, I think it is doable long-term.

@nshaffer
Copy link

Thanks for the ping @ivan-pi. I just finished reviewing the call. I think my general opinion on maintaining old, important packages under fortran-lang is very similar to @certik's. But to be explicit, and raise a few points that I think have not come up yet:

I would first like to see the f77 source maintained with minimal modifications. The initial commit can be the source as it is on netlib or in scipy, or whatever. From there, we can fix bugs (including standards-conformance issues), improve documentation, supply proper tests, and restructure to be packaged with fpm. This is the top priority if these packages are to remain useful for another 40-50 years. People will forget them and/or lose confidence in them if they just sit as tarballs on netlib. This repository should contain no API changes unless a bug is found that makes an existing API unsalvageable.

The "legacy" repository should also provide a nice f90 module interface to the library. The purpose is not to change the API at all, but rather to have an explicit interface for compilers to check. I think it would also be appropriate to define flags and return codes as module parameters with sensible names. In this f90 module, we should also provide C bindings wherever possible. If we can provide explicit f90 interfaces and "official" C bindings for these libraries, that will already be a big success and a service to scientific computing, in my opinion.

With that as the groundwork, I think it is also appropriate to have fortran-lang develop modernized packages. These can either be pretty wrappers around the f77 code (using the fortran-lang module as an entry point) or total rewrites using the f77 code as a reference. The point is this is a separate repo. I was initially inclined not to have these be under fortran-lang, to instead let users write their own. But this is basically what we have already: many people have their own little wrappers around whatever subset of LAPACK they use most. Sometimes they have tests, sometimes they don't. If those efforts are pooled together under fortran-lang, the result will be a more visible, more credible, and ultimately more useful package.

@rouson
Copy link

rouson commented Jun 22, 2021 via email

@certik
Copy link
Member

certik commented Jun 22, 2021

As I mentioned to Ondrej recently, I hope to live to see the day when
Fortran 90 is no longer considered modern.

I think we are all in agreement Damian. :) When I wrote Fortran 90, I did not mean in on purpose, it's just a habit. After you pointed that out, I try to just say "modern Fortran" instead. However, I have a request for you Damian also. We should not be using the .f90 extension for the same reason you just pointed out, but rather just the .f extension, see fortran-lang/fpm#363. I noted your opposition there, but I think you should reconsider. The extension might be even more important for the "optics" than mentioning "Fortran 90" in issue comments, because the file extension is seen all the time, everywhere, by every Fortran user.

@nshaffer
Copy link

Fair points, Damian. Indeed the Fortran 90 standard is a little older than I am (but only by a little). It's a bad habit of mine to use "f77" and "f90" as shorthand for "legacy" and "modern".

The idea of using submodules is interesting. So the gist would be to declare the interfaces in a module, then either copy-paste or include the fixed-form sources in a (fixed-form?) submodule file?

@arjenmarkus
Copy link
Member

arjenmarkus commented Jun 22, 2021 via email

@rouson
Copy link

rouson commented Jun 22, 2021 via email

@rouson
Copy link

rouson commented Jun 22, 2021 via email

@ilayn ilayn mentioned this issue Oct 9, 2021
Closed
@jacobwilliams
Copy link
Member

Well, I guess I had forgotten about this thread. I went ahead and modernized quadpack. See: https://github.com/jacobwilliams/quadpack

This is a full modernization & cleanup of the code (converted to free-form, removed obsolescent features, cleaned up the doc strings, etc.) It's now all in one module. The API is the same though! At least it is for the double precision version. I removed the single-precision routines and make it so you can create a single or even quad precision module using some preprocessing trickery.

I used the netlib/quadpack one as a starting point. That one has the recent bug fixes from SciPy. I need to see what else they have done.

My intent is to use this as an FPM dependency in my quadrature-fortran library, so I can use it for 1D-6D integration.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
10 participants
@certik @dhermes @arjenmarkus @milancurcic @jacobwilliams @rouson @nshaffer @ivan-pi @LKedward @awvwgk