fast quadratic form for dense matrix, sparse vectors

[matbesancon]

This was missing from the specializations and thus still slow.
This is a port from the same PR on FW.jl: ZIB-IOL/FrankWolfe.jl#607

[dkarrasch]

The doubly layered case (transpose of wrapper of dense) begs the question if that really occurs, and if yes, then what about the adjoint of wrappers of dense? Conversely, would it be too generic to have

function dot(a::AbstractSparseVector, Q::AbstractMatrix, b::AbstractSparseVector)
    return _dot_quadratic_form(a, Q, b)
end

ADD: It would actually correspond nicely to the existing

function dot(x::AbstractVector{T1}, A::AbstractSparseMatrixCSC{T2}, y::AbstractVector{T3}) where {T1,T2,T3}

[codecov]

Codecov Report

❌ Patch coverage is 80.64516% with 6 lines in your changes missing coverage. Please review.
✅ Project coverage is 84.00%. Comparing base (34ece87) to head (4c71b6b).
⚠️ Report is 1 commits behind head on main.

Files with missing lines	Patch %	Lines
src/linalg.jl	80.64%	6 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #640      +/-   ##
==========================================
- Coverage   84.01%   84.00%   -0.02%     
==========================================
  Files          12       12              
  Lines        9258     9288      +30     
==========================================
+ Hits         7778     7802      +24     
- Misses       1480     1486       +6     

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

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[matbesancon]

begs the question if that really occurs

that's the problem with method ambiguities, there is no way to prove Aqua that this is never the case

[matbesancon]

About the suggestion of

dot(a::AbstractSparseVector, Q::AbstractMatrix, b::AbstractSparseVector)

The issue is precisely
dot(x::AbstractVector{T1}, A::AbstractSparseMatrixCSC{T2}, y::AbstractVector{T3}) where {T1,T2,T3}

because this needs to be disambiguated again

[dkarrasch]

But we have

function dot(x::SparseVector, A::AbstractSparseMatrixCSC, y::SparseVector)

If you change it to

function dot(x::AbstractSparseVector, A::AbstractSparseMatrixCSC, y::AbstractSparseVector)

that would be the disambiguating method, wouldn't it?

[matbesancon]

Making it general was making a whole lot of ambiguities pop:
https://github.com/JuliaSparse/SparseArrays.jl/actions/runs/16826540584/job/47664254978?pr=640#step:6:118

[matbesancon]

Generalizing SparseVector to AbstractSparse in the other method worked though :)

[matbesancon]

ok all settled on my end, @dkarrasch can you take a look to see if things are all good for you?

[dkarrasch]

I believe we need these. The other use case is actually wrong. I'll need to fix it, and then backport the fix. Could you perhaps double check for one of the examples that we actually call the right method?

[matbesancon]

OK something interesting, there is an incorrect behavior somewhere:

using SparseArrays, LinearAlgebra, Random

Random.seed!(42)
A = sprand(ComplexF64, 10, 15, 0.4)
Av = view(A, :, :)
x = sprand(ComplexF64, 10, 0.5)
y = sprand(ComplexF64, 15, 0.5)
@test dot(y, Symmetric(collect(A)' * collect(A)), y) ≈ dot(y, Symmetric(A' * A), y)

fails on the current SparseArrays default (on 1.11)

[matbesancon]

Specifically this function:
https://github.com/JuliaSparse/SparseArrays.jl/blob/main/src/linalg.jl#L1245

[matbesancon]

The test will fail if we haven't overwritten the function

[dkarrasch]

Hm, this is another bug in the method signature:

dot(x::SparseVector, A::RealHermSymComplexHerm{<:Any,<:AbstractSparseMatrixCSC}, y::SparseVector)

needs to have <:Real instead of <:Any. This way, the function won't apply to sparse complex symmetric matrices. One could fix the complex symmetric case, but I don't think this is actually needed.

[dkarrasch]

A fix is coming in #643. Let's merge that one first, then update here and make sure we don't end up with ambiguities.

[matbesancon]

The tests are passing, good to merge I'd say