`svd` and friends fail for `BigFloat` and other non-primitive numbers.

[LilithHafner]

svd, svdvals, svdvals!, rank (and any functions that use these internally) do not support BigFloat. Presumably they also fail to support other non-BlasReal types.

julia> svd(BigFloat.(rand(5,5)))
ERROR: MethodError: no method matching svdvals!(::Matrix{BigFloat})

[dkarrasch]

I'm not sure this is in the scope of the stdlib LinearAlgebra.jl. That functionality is available at GenericLinearAlgebra.jl.

[StefanKarpinski]

One thing we could do is use method error hooks to give an error message that suggests using GenericLinearAlgebra. I can't for the life of me remember the name of that hook mechanism though, despite grepping through the repo for all the combinations of "method", "error" and "hook" that I can think of. Anyone remember what that mechanism is named?

[LilithHafner]

It seems somewhat odd to require another package to pirate LinearAlgebra.svd(::Base.AbstractMatrix).

[oscardssmith]

The medium-to-long term plan here (IMO) is to make GenericLinearAlgebra.jl as fast as the LAPACK routines, move it to Base, and remove our dependency on BLAS/LAPACK

[StefanKarpinski]

It is, but it's similar to how Base requires LinearAlgebra to pirate * for matvec and matmul. I'm not sure what to do about it. Either you're forced to move GenericLinearAlgebra into LinearAlgebra or you have some notion of "sanctioned piracy". At this point, GenericLinearAlgebra is mature and stable enough that it might make sense to merge it into LinearAlgebra, but I'm quite tempted to make excising LinearAlgebra as a stdlib a prerequisite for that, since we don't want to bloat what we ship even more.

[StefanKarpinski]

The medium-to-long term plan here (IMO) is to make GenericLinearAlgebra.jl as fast as the LAPACK routines, move it to Base, and remove our dependency on BLAS/LAPACK

ORLY, that's quite the ambitious plan! Is it really plausible to make GLA as fast as LAPACK? I guess it's mostly just the matmul part that actually needs to be fast, so I guess what you're really suggesting is removing the dependency on LAPACK but not on BLAS, which is much harder to match the speed of.

[oscardssmith]

I'm hopeful that LoopModels will let us replace BLAS with an Octavian-like thing.

[StefanKarpinski]

That would be great, but let's separate the straightforward, definitely doable thing—i.e. replacing and removing the dependency on LAPACK—from the extremely ambitious and slightly nuts thing—i.e. replacing and removing the dependency on BLAS. Even if both are possible, the timeline for the former can be much faster than the timeline for the latter. And for this issue, only the former is necessary.

[LilithHafner]

I'm going to re-open this with the understanding that it is unlikely to be fixed soon but would be nice to fix eventually and plans are already in the works to fix it.