scipy: cython_blas does not use const in signatures

Usually, BLAS interfaces for C use function signatures with const qualifiers - examples:

void F77_daxpy( FINT, const double *, const double *, FINT, double *, FINT);

F77_NAME(daxpy)(const int *n, const double *da,
		const double *dx, const int *incx,
		double *dy, const int *incy);

However, the Cython pxd file for cython_blas generates the function signatures without const qualifier:

cdef void daxpy(int *n, d *da, d *dx, int *incx, d *dy, int *incy) nogil

Which makes it harder to wrap into existing programs if they are using const.

About this issue

Original URL
State: closed
Created 3 years ago
Reactions: 2
Comments: 30 (30 by maintainers)

Commits related to this issue

BLD: Add const to Cython signatures for BLAS/LAPACK Use regex to parse CBLAS/LAPACK headers to infer whether an argument is const or not. Closes #14262 — committed to lysnikolaou/scipy by lysnikolaou a year ago
BLD: Add const to Cython signatures for BLAS/LAPACK Use regex to parse CBLAS/LAPACK headers to infer whether an argument is const or not. Closes #14262 — committed to lysnikolaou/scipy by lysnikolaou a year ago
BLD: Add const to Cython signatures for BLAS/LAPACK (#18247) * BLD: Add const to Cython signatures for BLAS/LAPACK Use regex to parse CBLAS/LAPACK headers to infer whether an argument is const or... — committed to scipy/scipy by lysnikolaou a year ago

Most upvoted comments

Unfortunately, we face issue which aren’t compile-time issues, as reported by https://github.com/scikit-learn/scikit-learn/issues/26290 and by https://github.com/Quantco/glum/issues/635.

jjerphan on May 1, 2023

This caused some breakage in scikit-learn; still a bit fuzzy what’s happening or what to do about it, but folks who were interested in this issue may want to follow gh-18377.

rgommers on Apr 28, 2023

Question: Is my understanding correct that the fortran symbols, used in scipy/linalg/_cython_signature_generator.py, are from LAPACK 3.4.0?

Yes, that looks correct - with the minor note that the routines that were removed in LAPACK 3.6.0 are not included in cython_lapack_signatures.txt, that should have been taken care of by commit 0528f14.

Use CBLAS headers to parse the function signatures and generate scipy/linalg/cython_blas_signatures.txt

I’m not sure about that. The cython_signature_generator.py script uses the Fortran headers and the Netlib BLAS/LAPACK sources. That script should already do the right thing, mostly. Maybe enhancing that script by fishing const arguments from CBLAS/LAPACKE headers would be easier than starting from scratch? Really not sure though, and the script is <200 LoC so maybe it’s not too bad to change it completely.

Question: If this makes sense, should we be using the LAPACK 3.7.1 headers (according to the toolchain roadmap). What if there are differences with the current list of exported symbols in scipy.linalg.blas? Should the list remain the same?

Using LAPACK 3.7.1 sounds good. It may drag in some new routines, and that’d be a good thing. If there are other differences that show up, then not sure - it depends on what those would look like.

rgommers on Apr 4, 2023

https://www.damnyouautocorrect.com I know we have a pandemic and all, but impunity is not immunity…

sturlamolden on Dec 23, 2021

It should be ok. The compiler will cast T * to const T * but not the other way around. It is the absence of const that cause the problems (i.e. requiring an explicit const_cast of const T * to T * when calling BLAS). Adding const qualifier to the prototypes can be done with impunity. It will only help to solve problems. It should not cause any backwards compatibility issues. In my opinion such a PR would be welcome.

sturlamolden on Dec 23, 2021