`opRestriction` and `opExtension` ignore `α` and `β` in 5-argument `mul!`
Nobody has claimed this yet.
Assessment
- Difficulty
- 2/5
- Estimated time
- 1-3 hours
- Newbie friendliness
- 85/100
- Issue type
- Bug
- Clarity
- Clearly specified
- Activity status
- Active
- Domain
- backend
Research direction
The bug is in the kernels mulRestrict! and multRestrict! in src/special-operators.jl, which accept α and β but never use them. Start there, then check how opRestriction and opExtension route the forward and adjoint products to these kernels. Run the reproduction from the issue; it is done when the 5-argument mul! returns α * op * v + β * res for both the forward and transposed cases.
Written by the indexing model from the issue text.
Description
mul!(res, op, v, α, β) should compute α * op * v + β * res, but for operators built by opRestriction (and opExtension, its transpose) the result is op * v: α and β are ignored in both the forward and the transposed/adjoint product.
using LinearOperators, LinearAlgebra
op = opRestriction([2, 4], 5)
res = ones(2)
mul!(res, op, [1.0, 2.0, 3.0, 4.0, 5.0], 2.0, 3.0)
res # [2.0, 4.0], expected [7.0, 11.0]
res = ones(5)
mul!(res, op', [1.0, 2.0], 2.0, 3.0)
res # [0.0, 1.0, 0.0, 2.0, 0.0], expected [3.0, 5.0, 3.0, 7.0, 3.0]
res = ones(5)
mul!(res, opExtension([2, 4], 5), [1.0, 2.0], 2.0, 3.0)
res # [0.0, 1.0, 0.0, 2.0, 0.0], expected [3.0, 5.0, 3.0, 7.0, 3.0]
Julia 1.10.12, LinearOperators 2.14.3.
The kernels in src/special-operators.jl take α and β but do not use them:
function mulRestrict!(res, I, v, α, β)
res .= view(v, I)
end
function multRestrict!(res, I, u, α, β)
res .= 0
res[I] = u
end
- Dominant language
- Julia
- Stars
- 214
- Forks
- 46
- PR merge metrics
- No merged PRs in 30d
Getting set up
- No Dockerfile or Docker Compose file
- No pull request template
- Read the contributing guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from JuliaSmoothOptimizers/LinearOperators.jl
-
Clarification of required fields for custom operatorsMay be free again @amontoison claimed this 249 days ago, and no pull request is open. Open
JuliaSmoothOptimizers/LinearOperators.jl#412 · 1 comment · 1 reaction · 1 assignee ·
-
Difficulty 3/5 1-2 days Newbie friendliness 45/100
JuliaSmoothOptimizers/LinearOperators.jl#393 · 1 comment ·
-
Difficulty 4/5 3-5 days Newbie friendliness 35/100
JuliaSmoothOptimizers/LinearOperators.jl#384 · 2 comments ·
-
Regularized Quasi-Newton operatorsMay be free again @molhab claimed this 572 days ago, and no pull request is open. Open
JuliaSmoothOptimizers/LinearOperators.jl#366 · 5 comments · 1 reaction · 2 assignees ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 45/100
All issues in JuliaSmoothOptimizers/LinearOperators.jl
Similar issues
-
`ShallowWaterModel` allocates ~9 KiB per grid point per RK3 stage on the CPUPossibly taken @ali-ramadhan claimed this today. Openperformance 🏍️
Difficulty 2/5 1-3 hours Newbie friendliness 62/100
CliMA/Oceananigans.jl#6421 · 1 reaction ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
JuliaQUBO/QUBOLib.jl#105 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 62/100
NCAR/musica#1118 · 1 comment · 1 reaction ·
Maintainers usually reply within 1 day
-
`AMSGrad` state starts at `epsilon` instead of zero, so zero gradients move parameters and small gradients are dampedPossibly taken @parth-patel010 claimed this 1 day ago. Open
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
FluxML/Optimisers.jl#247 · 1 comment ·
-
README should say that row and column order must matchPossibly taken @SAUMYARSH claimed this 1 day ago. Open
Difficulty 1/5 Under an hour Newbie friendliness 84/100