# LAPACK interfaces **URL:** \ **Category:** Uncategorized\ **Created:** [December 29, 2021, 8:17am UTC](https://fortran-lang.discourse.group/t/lapack-interfaces/2462 "2021-12-29T08:17:52Z")\ **Posts on this page:** 6\ **Page:** 3
**Author:** ![jkd2022](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/jkd2022/32/1949_2.png) [@jkd2022](https://fortran-lang.discourse.group/u/jkd2022)\ **Post date:** [August 18, 2023, 5:57pm UTC](https://fortran-lang.discourse.group/t/lapack-interfaces/2462/41 "2023-08-18T17:57:53Z")
> 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: ```auto 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: ```auto 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. ---
**Author:** ![Beliavsky](https://avatars.discourse-cdn.com/v4/letter/b/ba8739/32.png) [@Beliavsky](https://fortran-lang.discourse.group/u/Beliavsky)\ **Post date:** [August 18, 2023, 6:30pm UTC](https://fortran-lang.discourse.group/t/lapack-interfaces/2462/42 "2023-08-18T18:30:46Z")
Thanks. Downloading [LAPACK](https://github.com/Reference-LAPACK/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 *.f9`0 is lines such as ```auto 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. ---
**Author:** ![FortranFan](https://avatars.discourse-cdn.com/v4/letter/f/96bed5/32.png) [@FortranFan](https://fortran-lang.discourse.group/u/FortranFan)\ **Post date:** [August 18, 2023, 6:50pm UTC](https://fortran-lang.discourse.group/t/lapack-interfaces/2462/43 "2023-08-18T18:50:23Z")
> [@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? ---
**Author:** ![RonShepard](https://avatars.discourse-cdn.com/v4/letter/r/a3d4f5/32.png) [@RonShepard](https://fortran-lang.discourse.group/u/RonShepard)\ **Post date:** [August 18, 2023, 7:40pm UTC](https://fortran-lang.discourse.group/t/lapack-interfaces/2462/44 "2023-08-18T19:40:17Z")
> [@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. ---
**Author:** ![ivanpribec](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/ivanpribec/32/3290_2.png) [@ivanpribec](https://fortran-lang.discourse.group/u/ivanpribec)\ **Post date:** [August 18, 2023, 8:04pm UTC](https://fortran-lang.discourse.group/t/lapack-interfaces/2462/45 "2023-08-18T20:04:03Z")
> [@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](https://fortran-lang.discourse.group/t/resistance-to-modernization/4136) LFortran could enable Fortran libraries to progress, while allowing C users to benefit from domain libraries on platforms where Fortran compilers are not available. ---
**Author:** ![certik](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/certik/32/4_2.png) [@certik](https://fortran-lang.discourse.group/u/certik)\ **Post date:** [August 21, 2023, 11:39pm UTC](https://fortran-lang.discourse.group/t/lapack-interfaces/2462/46 "2023-08-21T23:39:31Z")
Once LFortran matures, you should be able to transpile any modern Fortran code to C, if you wanted. [Previous page](https://fortran-lang.discourse.group/t/lapack-interfaces/2462.md?page=2)