LAPACK interfaces

[jkd2022]

It’s a problem when arguably the most important library for a language is maintained by people with no interest in exploiting the benefits of the current version of the language.

I noticed that they are starting to modernize BLAS/LAPACK in the most recent releases.

Consider zlassq.f from version 3.9.0:

      SUBROUTINE ZLASSQ( N, X, INCX, SCALE, SUMSQ )
*
*  -- LAPACK auxiliary routine (version 3.7.0) --
*  -- LAPACK is a software package provided by Univ. of Tennessee,    --
*  -- Univ. of California Berkeley, Univ. of Colorado Denver and NAG Ltd..--
*     December 2016
*
*     .. Scalar Arguments ..
      INTEGER            INCX, N
      DOUBLE PRECISION   SCALE, SUMSQ
*     ..
*     .. Array Arguments ..
      COMPLEX*16         X( * )
...

and the same subroutine (now zlassq.f90) from version 3.11:

subroutine ZLASSQ( n, x, incx, scl, sumsq )
   use LA_CONSTANTS, &
      only: wp=>dp, zero=>dzero, one=>done, &
            sbig=>dsbig, ssml=>dssml, tbig=>dtbig, tsml=>dtsml
   use LA_XISNAN
!
!  -- LAPACK auxiliary routine --
!  -- LAPACK is a software package provided by Univ. of Tennessee,    --
!  -- Univ. of California Berkeley, Univ. of Colorado Denver and NAG Ltd..--
!
!  .. Scalar Arguments ..
   integer :: incx, n
   real(wp) :: scl, sumsq
!  ..
!  .. Array Arguments ..
   complex(wp) :: x(*)
...

It’s going to be a long effort though and I doubt they’ll use anything which will restrict the library from being called exclusively from Fortran, such as optional arguments or assumed shape or rank arrays.

[Beliavsky]

Thanks. Downloading LAPACK and counting the number of source files with intent using the Windows command findstr -i -s -m intent *.f *.f90 | wc gives 30 30 564 (so 30 files with intent), and the output of findstr -i -s intent *.f *.f90 is lines such as

src\SRC\cgedmd.f90:      CHARACTER, INTENT(IN)   :: JOBS,   JOBZ,  JOBR,  JOBF
src\SRC\cgedmd.f90:      INTEGER,   INTENT(IN)   :: WHTSVD, M, N,   LDX,  LDY, &
src\SRC\cgedmd.f90:      INTEGER,       INTENT(OUT)  :: K, INFO
src\SRC\cgedmd.f90:      REAL(KIND=WP), INTENT(IN)   ::    TOL

so they are using argument intents in a small fraction of their procedures. Presumably pull requests could increase that number.

[FortranFan]

@jkd2022

Suppose you have to perform many diagonalizations on small arrays. You will want to avoid the overhead of allocate and deallocate (effectively malloc() and free()) by reusing the work arrays. The LAPACK interface accommodates this

Can you point to a working example of this?

[RonShepard]

@jkd2022

Suppose you have to perform many diagonalizations on small arrays. You will want to avoid the overhead of allocate and deallocate (effectively malloc() and free()) by reusing the work arrays. The LAPACK interface accommodates this.

Yes, this is a way to avoid putting allocation/deallocation inside of an otherwise tight loop. Another nice feature of this approach is when you string together several lapack calls to do some complicated kind of operation. The programmer can do workspace queries on all of the routines keeping track of the maximum workspace, then do a single workspace allocation of that length, and then share/reuse that same workspace array in each of the subroutine calls.

[ivanpribec]

@PierU

Actually, quickly browsing some discussions on the LAPACK github, it seems that their main argument against incorporating modern Fortran features into LAPACK is because they want the code to be transcodable with f2c.

I initiated that discussion. I find the identified f2c reason uncompelling. On some Linux distributions at least, f2c is already broken. We had a discussion of it here: Resistance to modernization

LFortran could enable Fortran libraries to progress, while allowing C users to benefit from domain libraries on platforms where Fortran compilers are not available.

[certik]

Once LFortran matures, you should be able to transpile any modern Fortran code to C, if you wanted.