Linear Algebra API: call for feedback

Announcements
1

Dear all:

I would like to call for your feedback on the initial BLAS/LAPACK and Linear Algebra API for the Fortran-lang stdlib.

Summary of the current features

  • BLAS and LAPACK fully modernized, with KIND-agnostic interface
  • For the first time ever, full quad-precision support
  • solve, inv, det, lstsq, eye, diag

External Library

If you have an external LAPACK/BLAS implementation, just ensure that:

  • STDLIB_EXTERNAL_BLAS and STDLIB_EXTERNAL_LAPACK are defined (e.g., in fpm.toml)
  • Link steps are undertaken.

For example, on macOS, just run

fpm build --flag "-framework Accelerate"

Trying it out

The library is currently hosted as GitHub - perazz/fortran-lapack: Modularized Fortran LAPACK implementation as an FPM package. To test it, you can either use it directly:

git clone https://github.com/perazz/fortran-lapack.git
fpm test

Or request it as a dependency in your FPM package:

[dependencies]
fortran-lapack = { git="https://github.com/perazz/fortran-lapack.git" }

A full discussion of the API is reported on the project’s homepage.

We are eager to receive your feedback! Best channels to do it are :

  • here on Discourse
  • Open Issues on the repo’s GitHub page

The Sovereign Tech Fund (STF) is also gratefully acknowledged for enabling this effort.
And goes without saying, many thanks to the Fortran-lang admins and supporters!

Thank you,
Federico

22 Likes
2

The site mentions a function

solve(A,b,overwrite_a,err): option to let A be destroyed, return state handlererr`

I don’t think functions should modify their arguments and suggest having a subroutine invoked with

call solve(A, b, sol, overwrite_a, err)

and a function that returns the solution.

solution(A,b)

where A is intent(in)

5 Likes
3

Great work! I think that it would make sense to leverage FlexiBLAS and get access to different implementations of BLAS and LAPACK.

1 Like
4

Thank you @Beliavsky @ricriv, we also discussed that yesterday at the Monthly call (thanks @everythingfunctional @hkvzjal @jeremie.vandenplas and others).

I have been misled by the NumPy and SciPy APIs, which work like that. There is no reason to do that in Fortran, because we can have a subroutine interface (although it has to be a different name, like x=inv(A) vs. call invert(A)).

I have opened an issue at API style definition · Issue #44 · perazz/fortran-lapack · GitHub, feel free to continue the discussion there.

1 Like
5

@FedericoPerini This is amazing work! I’m going to try it out.

If I’m seeing this right, I could be able to replace link = ["lapack", "blas"] in my fpm.toml files with this library as a dependency. Then if I want to use an external lapack I can use the preprocessor directives plus the appropriate link flags to make that happen? But if I want a real128 version I don’t use the external lib and it will “just work”?

1 Like
6

Exactly @jacobwilliams, eager to receive your feedback :saluting_face:

  • The internal implementation provides real32, real64 and real128 versions at all times via the stdlib_ prefix: so, if you are also linking to external BLAS/LAPACK, they will not collide
  • There is a KIND-agnostic interface in modules stdlib_linalg_blas and stdlib_linalg_lapack, for example, call gemv will work for any precisions (but no mixed-precision, i.e., real64 matrix and real32 array, yet
  • If macros STDLIB_EXTERNAL_BLAS and/or STDLIB_EXTERNAL_LAPACK are defined, the generalized interface will use the external library instead of the internal implementation, only for 32- and 64-bit versions
  • The real128 version is always available, and always points to the internal implementation

Please note that, although the 128-bit was derived by generalizing all machine constants, it has only been subject to limited testing yet, so if you have established 128-bit use cases (to derive RK or ODE method constants, for example!) and/or find issues, I’m happy to look into it and add more tests!

1 Like
8

It would be better to provide detailed instructions of using OpenBLAS or MKL as the backend on various platforms.

1 Like
9

Thank you @fortran4r - love the idea. The library so far showcases that it is designed to easily enable linking of external implementations.

The current plan is to merge the whole API into the Fortran-lang Standard Library, so, the BLAS/LAPACK backend will be handled by CMake. Later, we will address BLAS/LAPACK dependencies for the Fortran Package Manager ecosystem, and they will be a “metapackage” i.e. similar to what CMake find_package does, so, hopefully, literally nothing to do on the user side!