# Linear Algebra API: call for feedback

**URL:** <https://fortran-lang.discourse.group/t/linear-algebra-api-call-for-feedback/7455>\
**Category:** Announcements\
**Created:** [February 22, 2024, 6:17pm UTC](https://fortran-lang.discourse.group/t/linear-algebra-api-call-for-feedback/7455 "2024-02-22T18:17:32Z")\
**Posts on this page:** 14\
**Page:** 1

<div class="post-metadata">

**Author:** ![FedericoPerini](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/federicoperini/32/1750_2.png) [@FedericoPerini](https://fortran-lang.discourse.group/u/FedericoPerini)\
**Post date:** [February 22, 2024, 6:17pm UTC](https://fortran-lang.discourse.group/t/linear-algebra-api-call-for-feedback/7455/1 "2024-02-22T18:17:32Z")

</div>

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

```auto
fpm build --flag "-framework Accelerate"

```

**Trying it out**

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

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

```

Or request it as a dependency in your FPM package:

```toml
[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

---

<div class="post-metadata">

**Author:** ![Beliavsky](https://avatars.discourse-cdn.com/v4/letter/b/ba8739/32.png) [@Beliavsky](https://fortran-lang.discourse.group/u/Beliavsky)\
**Post date:** [February 23, 2024, 2:33am UTC](https://fortran-lang.discourse.group/t/linear-algebra-api-call-for-feedback/7455/2 "2024-02-23T02:33:22Z")

</div>

The site mentions a function

> solve(A,b,overwrite\_a,err)`: option to let A be destroyed, return state handler`err`

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)`

---

<div class="post-metadata">

**Author:** ![ricriv](https://avatars.discourse-cdn.com/v4/letter/r/f17d59/32.png) [@ricriv](https://fortran-lang.discourse.group/u/ricriv)\
**Post date:** [February 23, 2024, 7:18am UTC](https://fortran-lang.discourse.group/t/linear-algebra-api-call-for-feedback/7455/3 "2024-02-23T07:18:54Z")

</div>

Great work! I think that it would make sense to leverage [FlexiBLAS](https://gitlab.mpi-magdeburg.mpg.de/software/flexiblas-release) and get access to different implementations of BLAS and LAPACK.

---

<div class="post-metadata">

**Author:** ![FedericoPerini](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/federicoperini/32/1750_2.png) [@FedericoPerini](https://fortran-lang.discourse.group/u/FedericoPerini)\
**Post date:** [February 23, 2024, 7:31am UTC](https://fortran-lang.discourse.group/t/linear-algebra-api-call-for-feedback/7455/4 "2024-02-23T07:31:08Z")

</div>

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](https://github.com/perazz/fortran-lapack/issues/44), feel free to continue the discussion there.

---

<div class="post-metadata">

**Author:** ![jacobwilliams](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/jacobwilliams/32/10_2.png) [@jacobwilliams](https://fortran-lang.discourse.group/u/jacobwilliams)\
**Post date:** [March 4, 2024, 12:15am UTC](https://fortran-lang.discourse.group/t/linear-algebra-api-call-for-feedback/7455/5 "2024-03-04T00:15:14Z")

</div>

@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”?

---

<div class="post-metadata">

**Author:** ![FedericoPerini](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/federicoperini/32/1750_2.png) [@FedericoPerini](https://fortran-lang.discourse.group/u/FedericoPerini)\
**Post date:** [March 4, 2024, 7:29am UTC](https://fortran-lang.discourse.group/t/linear-algebra-api-call-for-feedback/7455/6 "2024-03-04T07:29:07Z")

</div>

Exactly @jacobwilliams, eager to receive your feedback 🫡

- 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!

---

<div class="post-metadata">

**Author:** ![fortran4r](https://avatars.discourse-cdn.com/v4/letter/f/9de0a6/32.png) [@fortran4r](https://fortran-lang.discourse.group/u/fortran4r)\
**Post date:** [March 8, 2024, 2:20am UTC](https://fortran-lang.discourse.group/t/linear-algebra-api-call-for-feedback/7455/8 "2024-03-08T02:20:16Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![FedericoPerini](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/federicoperini/32/1750_2.png) [@FedericoPerini](https://fortran-lang.discourse.group/u/FedericoPerini)\
**Post date:** [March 8, 2024, 7:29am UTC](https://fortran-lang.discourse.group/t/linear-algebra-api-call-for-feedback/7455/9 "2024-03-08T07:29:01Z")

</div>

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!

---

<div class="post-metadata">

**Author:** ![jacobwilliams](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/jacobwilliams/32/10_2.png) [@jacobwilliams](https://fortran-lang.discourse.group/u/jacobwilliams)\
**Post date:** [January 6, 2025, 4:41am UTC](https://fortran-lang.discourse.group/t/linear-algebra-api-call-for-feedback/7455/10 "2025-01-06T04:41:44Z")

</div>

@FedericoPerini I finally got around to trying this, and it is amazing! The `real128` versions are working great for me (I’m only using a few routines but it’s a good sign). Terrific work!

Is the one at [GitHub - perazz/fortran-lapack: Modern Fortran Linear Algebra library](https://github.com/perazz/fortran-lapack.git) considered deprecated now? Should I be using what is in stdlib now? I tried it but the quad precision ones don’t seem to be there in the stdlib-fpm version? (e.g., `stdlib_linalg_lapack_q.F90` is a blank file?) Maybe I’m doing something wrong?

---

<div class="post-metadata">

**Author:** ![hkvzjal](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/hkvzjal/32/3055_2.png) [@hkvzjal](https://fortran-lang.discourse.group/u/hkvzjal)\
**Post date:** [January 6, 2025, 6:09am UTC](https://fortran-lang.discourse.group/t/linear-algebra-api-call-for-feedback/7455/11 "2025-01-06T06:09:15Z")

</div>

@jacobwilliams you are not doing anything wrong, the deployment script is deploying only for single and double precision. See here [stdlib/.github/workflows/fpm-deployment.yml at b5b86a714a3baab4e41205c88d9ea57efc888fd4 · fortran-lang/stdlib · GitHub](https://github.com/fortran-lang/stdlib/blob/b5b86a714a3baab4e41205c88d9ea57efc888fd4/.github/workflows/fpm-deployment.yml#L39). It can be easily changed, should it?

In the meantime, if you have the main branch uptodate, you can build directly from root (without the need to branching to `stdlib-fpm`) with fpm and customize the fypp pre-preprocessing following these steps [GitHub - fortran-lang/stdlib: Fortran Standard Library](https://github.com/fortran-lang/stdlib?tab=readme-ov-file#build-with-fortran-langfpm)

For instance:

```shell
python config/fypp_deployment.py --with_xdp --with_qp

```

Will pre-preprocess to enable `xdp` and `qp`.

---

<div class="post-metadata">

**Author:** ![FedericoPerini](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/federicoperini/32/1750_2.png) [@FedericoPerini](https://fortran-lang.discourse.group/u/FedericoPerini)\
**Post date:** [January 6, 2025, 3:08pm UTC](https://fortran-lang.discourse.group/t/linear-algebra-api-call-for-feedback/7455/12 "2025-01-06T15:08:59Z")

</div>

> [@jacobwilliams](#):
>
> considered depreciated now

`stdlib` is the up-to-date and complete implementation right now: lapack [has fixes](https://github.com/fortran-lang/stdlib/pull/836), @hkvzjal has [dramatically improved](https://github.com/fortran-lang/stdlib/pull/913) the build process, etc.

> [@jacobwilliams](#):
>
> `stdlib_linalg_lapack_q.F90` is a blank file?

I also noticed that. It may be that quadruple precision was originally leftover from the `stdlib-fpm` branch just to avoid crashing if a compiler didn’t have support. (`qp` is pre-processed with fypp, not with C preprocessor directives, so it can’t be templated by fpm). But which compilers don’t have 128-bit reals these days?

Note that we’ve recently added a `stdlib-fpm-ilp64` branch that includes both 32- and 64-bit integer precisions. @hkvzjal: maybe, we could include `--WITH_QP` by default in that branch? It would make sense to me as a “feature-complete” branch.

---

<div class="post-metadata">

**Author:** ![cmaapic](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/cmaapic/32/659_2.png) [@cmaapic](https://fortran-lang.discourse.group/u/cmaapic)\
**Post date:** [January 6, 2025, 4:52pm UTC](https://fortran-lang.discourse.group/t/linear-algebra-api-call-for-feedback/7455/13 "2025-01-06T16:52:32Z")

</div>

The nvidia and Silverfrost/Salford compilers don’t have 128 bit real support.

---

<div class="post-metadata">

**Author:** ![hkvzjal](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/hkvzjal/32/3055_2.png) [@hkvzjal](https://fortran-lang.discourse.group/u/hkvzjal)\
**Post date:** [January 6, 2025, 5:12pm UTC](https://fortran-lang.discourse.group/t/linear-algebra-api-call-for-feedback/7455/14 "2025-01-06T17:12:55Z")

</div>

> [@FedericoPerini](#):
>
> @hkvzjal: maybe, we could include `--WITH_QP` by default in that branch? It would make sense to me as a “feature-complete” branch.

That makes sense!!

@cmaapic can the Silverfrost compiler build `stdlib`? I know that nvfortran cannot, even without talking about 128 bit real support.

---

<div class="post-metadata">

**Author:** ![Harper](https://avatars.discourse-cdn.com/v4/letter/h/b5ac83/32.png) [@Harper](https://fortran-lang.discourse.group/u/Harper)\
**Post date:** [January 6, 2025, 8:27pm UTC](https://fortran-lang.discourse.group/t/linear-algebra-api-call-for-feedback/7455/15 "2025-01-06T20:27:48Z")

</div>

Lfortran did not have 128 bit real support the last time I looked.
