What should be part of stdlib?

[milancurcic]

Existing libraries, for inspiration or adoption

• Awesome Fortran
• flibs by @arjenmarkus
• fortran-utils by @certik
• Polycon by @cmacmackin
• Stefano Zaghi made a lot of good stuff
• datetime-fortran and functional-fortran by myself
• SciFortran by @aamaricci
• Coretran by @leonfoks
• Futility
• General-Purpose Fortran by @urbanjost
• A FORTRAN 90 Numerical Library by Alberto Ramos
• Many others -- if we missed anything, please let us know

---

First issue in this repo which evolved from this thread. This is a broad, open ended, high-level issue, so feel free to go wide and crazy here.

To propose a specific module, procedure, or derived type, please open a new issue. You can follow the same format as in Fortran Proposals.

Wishlist from upthread

From @apthorpe:

• What I miss when writing Fortran
• What should a Fortran stdlib contain, Part 1
• What should a Fortran stdlib contain, Part 2

---

From @FortranFan:

• Containers
  • string type
  • bitsets
  • Enhanced 'array' types such as vectors, singly-linked and doubly-linked lists, etc.
  • Adapters such as stacks, queues, etc.
  • Associative ones such as dictionaries (maps), hash_sets, etc.
• Algorithms
  • Generic methods for sort, findloc, etc. that can work with any type, intrinsic and derived,
  • Operations and permutations on a range of elements such as merge/union, difference,
    etc.
• Utilities
  • Iterator-like facilities which make it easy to work with Containers,
  • Operator (<, >, ==, etc. ) and assignment(=) overload abstractions that perhaps make
    the use of standard algorithms more efficient?
  • Miscellaneous other functions, subroutines (like generic swap), datetime, named
    constants, etc.
• Special
  • Any basic facilities (extensions perhaps to ABSTRACT INTERFACE block?) needed toward
    "special" functions such as Variadic ones in the language e.g., MAX, MIN
  • Ability to "overload" array subsection notation facility with Containers that standard Fortran
    provides with its 2 built-in containers: arrays and CHARACTER intrinsic type.
  • Any special mechanisms that can help aid with improved constructors of arrays/containers
    and derived types ('classes'). I envision certain fundamental 'computer engineering' aspects
    being pursued here that can enable, say, efficient operation on the diagonal of a matrix or
    initialization to an identity matrix; or efficient 'dynamic' construction of 'classes' in Fortran similar
    to that is achieved near universally using new keyword in other languages.

---

From @zbeekman:

• Strings
  • Conversion to/from integer/real/logical (all kinds of each)
  • Conversion on string concatenation
  • raw string processing functions inspired by Ruby & Python
  • string class to make using all the machinery easier via TBPs
• Files
  • For now just name manipulations like dirname, basename, etc.
• OS/Environment integration
  • is_a_tty(), OS%env("HOME"), .envExists. "USER", etc.
• Unit testing & assertions stuff
  • Subtest summaries w/ color
  • File and line number triggering failures
• Error Stack class/object
  • Maintain a call-stack
  • Raise errors, but optionally trap them later with good call stack including line number and file

[FortranFan]

@milancurcic wrote:

..

• Many others -- what did I miss?

Great start, perhaps @tclune et al at NASA with https://github.com/nasa/gFTL can contribute or be an inspiration?

[ivan-pi]

The D standard library can also serve as reference/inspiration: https://dlang.org/library/. For many of the D modules there are already some existing open-source modules in Fortran (like dealing with CSV and JSON files, datetime objects, low-level string operations).

Inspired by the D library, I prepared a bunch of functions for checking ASCII characters: https://github.com/ivan-pi/fortran-ascii

[ivan-pi]

Several interesting modules are available in the General-Purpose Fortran package (command line arguments, strings, expression parsers,messages, io, hot keys, fortran/C calls, graphics, sorting, unit conversions).

George Benthien has also made some string utilities and expression parsers.

Also Alan Miller's Fortran software contain many routines that are suitable for a stdlib.

The Rosetta Code Fortran pages contain simple implementations of several algorithms (greatest common divisors, sorting, searching, etc.) and data types (priority queues, decks, linked lists, etc.).

[marshallward]

I would like to see greater support for bit-reproducible numerical operations. This is a very high priority for us since our models are used in weather and climate forecasting, and much of our time is devoted to bit reproducibility of our numerical calculations.

A common problem is intrinsic Fortran reduction operations like sum(), where the order is ambiguous (deliberately, one might say), and therefore not reproducible. A more serious problem for us is transcendental functions, like exp() or cos(), which will give different results for different optimizations, and we typically cannot say where it was invoked (libm? Vendor library? etc.).

A standard library may be a place to provide bit-reproducible implementations.

[rweed]

Fortunately, there is a wealth of libraries etc we can draw from. Some of the older ones like SLATEC etc are still in F77 but can be converted to F90 free format for consistency. One issue that needs to be resolved though are possible license conflicts. Here are a few more suggestions (there are probably a hundred more if we do a deep dive into whats available)

For general mathematical functions etc.

SLATEC/nistCML
https://www/nist/gov/itl/math/software
https://www.netlib.org/slatec
https://people.sc.fsu.edu/~jburkardt/f_src/slatec/slatec.html (F90 translation)

John Burkardt's collection of software at
https://people.sc.fsu.edu/~jburkardt/f_src/f_src.html

For containers/ADTs, I would suggest Robert Ruegers Fortran Template Library at
https://github.com/SCM-NV/ftl
Similar to @tclune gFTL but Ruegers implementations of the various containers and how he does the preprocessing step was easier for me to follow

Two books that have available code that I would suggest are Robin Vowels, "Algorithms and Data Structures in F and Fortran" and Dick Hanson and Tim Hopkins, "Numerical Computing in Modern Fortran". I've implemented some of the sorting routines from both books. In particular, I have a "semi"-generic implementation of Hanson and Hopkins quickSort routines that support all the integer types, 32 and 64 bit reals, character strings, and a user type/class. I have my own implementations of several commonly used ADTs based on unlimited polymorphic variables that I can contribute for reveiw but I need to go back and look at licensing issues since I borrowed ideas from Arjen Markus FLIBS, and Rueger's FTL. Also, I would personally avoid anything related to Numerical Recipes like the plague due to their restrictive license (and poor implementations of some of the algorithms)

[certik]

@marshallward I created #12 for bit-reproducibility, let's discuss the details there.

[jacobwilliams]

One big question is, do we want this library to contain numerical/scientific type codes? For example, ODE solvers, optimizers, interpolation, etc... The sorts of things that were in SLATEC and are in SciPy. A library like that is desperately needed for modern Fortran. Is that this library, or does that belong in another library built upon this one?

[certik]

@jacobwilliams excellent question. I don't know the answer, we need to discuss it. I am a bit worried if the scope does not become too much if we include everything that potentially can be in SciPy.

[milancurcic]

I am not opposed to numerical and scientific codes being part of stdlib. The scope of Fortran's stdlib doesn't necessarily need to be similar to that of Python, C, or any other language. Fortran is more ubiquitous in science and engineering, and to me it makes sense that the stdlib would have modules similar to numpy and scipy.

[milancurcic]

One personal challenge I have with stock Fortran are its somewhat awkward and low-level I/O facilities -- open, read, write, inquire, rewind, and close. I often wished for a higher-level interface, like what you get with Python's open() -- you open a file with a function, get a file-like instance with methods that let you do stuff with it.

This would do away with unit numbers, which I don't think application developers should have to deal with. It could also be a solution to the problem that allocatable character strings must be pre-allocated before use on read statement.

Is there anything similar out there for Fortran? Would this be of interest to people here? I'd use it.

[certik]

If we want to go with this broader scope, then one reasonable proposal can be to limit the scope roughly to what is in here:

https://www.mathworks.com/help/matlab/mathematics.html

Which seems to cover roughly what is in NumPy and SciPy.

If we use the Python analogy, the bare bone Python language does not have much for numerical computing. And if you do any kind of numerical computing in Python (I do), NumPy and SciPy are pretty much the "standard library". Not surprisingly, the default "Matlab standard library" roughly covers the same range.

The Julia standard library (https://github.com/JuliaLang/julia/tree/5da74be66993fb19edce52e4877d8ae2edbe27b0/stdlib, documented at https://docs.julialang.org, in the left column scroll down to "Standard Library") does not cover as wide range, but still includes linear algebra (Lapack), sparse arrays, statistics. It used to contain fft, but they moved it out apparently (https://discourse.julialang.org/t/where-is-the-fft/16512) -- it would be interesting to know the reasoning, as Matlab as well as NumPy has fft by default.

Ok, it's not a bad idea.

[jvdp1]

Is there anything similar out there for Fortran? Would this be of interest to people here? I'd use it.

I would use it too.

Something that might be interesting to include in a standard library is sparse arrays (creation, management).

[certik]

I think we can learn from Julia a lot. Here is the discussion related to moving FFT out of Julia's standard library and into a separate package:

JuliaLang/julia#18389

and apparently they want to also move much of the linear algebra out. See also:

https://groups.google.com/forum/#!topic/julia-users/ug5Jh6y5biA.

JuliaLang/julia#5155

If I understand their arguments, if it's part of the julia compiler itself, it's hard for them to make a release, test things properly on Travis, etc. Applied to Fortran, that would be like moving things from Fortran compilers (gfortran, ifort, ...) into a separate library like this stdlib.