Skip to content

lstsq(alg=:iterative) blanket-rejects non-BLAS eltypes, yet the iterative engine works in BigFloat #13

@ChrisRackauckas-Claude

Description

@ChrisRackauckas-Claude

WHAT: _check_lstsq_eltype (src/lstsq.jl:30-41) is called by all three engines, including iterative (ext/...IterativeSolversExt.jl:22). But the iterative engine uses only the structured matvec/adjoint + IterativeSolvers.lsqr/lsmr — none need BLAS floats. Confirmed: a rank-deficient BigFloat A via lsqr converged to relerr 1.6e-15 vs the pinv oracle, yet lstsq(A, b; alg=:iterative) throws ArgumentError. WHY IT MATTERS: A real capability is needlessly suppressed — high-precision Newton in BVP solvers is the package's target regime. The guard is correct for :dense (LAPACK gelsy) but wrong for :iterative. FIX: Move the BLAS-float guard out of the shared entry into the dense/structured paths only; in the iterative engine check for real/complex AbstractFloat (still rejects Int/Rational, lets BigFloat/Complex{BigFloat}/Float16 through). Add the Int-rejection test plus a BigFloat iterative test. Update the docstring/README ('Only Float32/Float64/...'). Pairs with documenting that :structured/:dense are BLAS-float-only by design (the :structured SVD needs GenericLinearAlgebra) and directing generic-eltype users to :iterative. EFFORT: S.


Priority: medium. Filed from an automated next-steps audit of the QR/lstsq work (see PR #6).

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions