Hi,
Internally, the majority of scipy.lapack uses LAPACK for computations. LAPACK functions only handle single/double precision real/complex arrays, but scipy.lapack python wrappers accept a wider range of dtypes: for one, integer arrays get converted to the default float64. What is worse though, many functions accept other dtypes (datetimes, float16, longdouble), and do it inconsistently: different functions make different decisions about non-LAPACK dtype inputs [1].
As a data point, numpy.linalg only accepts float{32,64} and complex{64,128}.
Here’s a proposal to formulate a consistent dtype policy for scipy.linalg and deprecate historical artifacts. In short, the suggestion is to follow numpy.linalg and reject “weird” dtypes. Specifically, make it so that
- integers keep being promoted to float64,
- float{32,64}, complex{64,128} pass through,
- anything else is rejected,
- output dtype = input dtype (with the only exception of integer → float64).
The main affected dtypes are
- longdoubles : these are system-dependent, and are currently downcast to double precision anyway
- float16 : currently they are upcast to float32. There’s a discussion in [2] about whether we should keep the current behavior (best not), downcast the result back to float16 (I suggest not) or ask the user to handle dtypes in the userland (my suggestion is yes).
Thoughts?
Please comment here or in the RFC issue [1] or the PR which implements the “strict” suggestion [2].
Cheers,
Evgeni
[1] RFC: make dtype handling uniform across `scipy.linalg` · Issue #24505 · scipy/scipy · GitHub
[2] DEP: linalg: deprecate using linalg functions with LAPACK-incompatible dtypes by ev-br · Pull Request #24682 · scipy/scipy · GitHub