Skip to content

Conversation

@pawel-tarasiuk-quantumz
Copy link
Contributor

LibSuiteSparse methods called from qr! might return structures with dtype that doesn't match the element type of matrix to factorize. This occurs for Tv=Float32 and Julia >=1.11.

Should fix #585

@codecov
Copy link

codecov bot commented Nov 26, 2024

Codecov Report

Attention: Patch coverage is 85.71429% with 1 line in your changes missing coverage. Please review.

Project coverage is 84.07%. Comparing base (9731aef) to head (4206c28).
Report is 1 commits behind head on main.

Files with missing lines Patch % Lines
src/solvers/cholmod.jl 80.00% 1 Missing ⚠️
Additional details and impacted files
@@            Coverage Diff             @@
##             main     #586      +/-   ##
==========================================
+ Coverage   84.03%   84.07%   +0.04%     
==========================================
  Files          12       12              
  Lines        9183     9188       +5     
==========================================
+ Hits         7717     7725       +8     
+ Misses       1466     1463       -3     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

@ViralBShah ViralBShah merged commit 268d390 into JuliaSparse:main Nov 26, 2024
10 checks passed
ViralBShah pushed a commit that referenced this pull request Feb 17, 2025
I fixed the same bug as #585, without realizing that it had already been
done. It wasn't a complete waste of time, because the PR #586 left some
cleanup to do: the lines
```julia
LinearAlgebra.qr(A::SparseMatrixCSC{<:Union{Float16,Float32}}; tol=_default_tol(A)) =
    qr(convert(SparseMatrixCSC{Float64}, A); tol=tol)
LinearAlgebra.qr(A::SparseMatrixCSC{<:Union{ComplexF16,ComplexF32}}; tol=_default_tol(A)) =
    qr(convert(SparseMatrixCSC{ComplexF64}, A); tol=tol)
```
would have prevented it from working if they actually worked! Luckily
they don't, as the correct method is more specific and gets called, but
it's still worth fixing. I also changed them to convert `Float16` to
`Float32` instead of `Float64`, and the analogous change for complex
numbers.

I also fixed the error messages one gets. They were of the form
"dtype=$(s.dtype) not supported", which in my case translated to saying
that `Float64` wasn't supported when I tried calling it with `Float32`.
`s.dtype` is the type that actually got computed, so it clearly is
supported. I changed them to say "dtype=$(dtyp(Tv)) not supported".
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Broken dtype detection in CHOLMOD in 1.11

2 participants