Evgeni Burovski

I'd also note that the wrapping story is special in scipy.special. what was in fortran and now is in c/c++ are kernels, which are the wrapped into ufuncs and cython_special.pxd.

(Edited for fat-finger errors) What I'm saying is that in scipy.special everything works as is for ufuncs and is easiest to make work in cython for cython_special IIUC. So nanobind...

Thanks Ilhan for the link. Binary size and build time improvements are nice indeed (one thing I miss from Fortran is build times). That said, runtime performance in these benchmarks...

> I can imagine pushing some of the array crunching cython code to C level since except linalg we use float64 and complex128 as data types. > But this is...

> Use case: In scikit-learn we use scipy.interpolate.BSpline for our SplineTransformer. BSpline is ... written in C. Therefore, it only accepts numpy arrays. This makes it hard for scikit-learn to...

> I tested with a simple function and it worked with numpy and torch as input. Whoa. More details on this please! Are you saying that given a C function...

Okay, some progress: CI is all green for both existing jobs and the added ILP64 job; Locally, the smoking gun test is passing, too: $ python dev.py build -C-Dblas=mkl -C-Duse-ilp64=true...

> Is it going to be compile-time or runtime switch you have in mind? Build time only, sorry. Need to have MKL when building scipy. Can you build with MKL...

> But the calls to BLAS/LAPACK, I don't know if possible to do if the symbol names are going to be varying. Here's a branch: https://github.com/ev-br/scipy/compare/ilp64...ev-br:scipy:nnls_ilp64?expand=1 Currently it passes all...

Thanks for the review Ralf! I addressed (almost) all review comments, and added a CI job to illustrate a build with `scipy-openblas64` (which needs both `scipy-openblas32` and `scipy-openblas64`).