Precision loss in Hessian computation
I maintainer di solito rispondono entro 1 giorno
Valutazione
- Difficoltà
- 5/5
- Tempo stimato
- Più di una settimana
- Idoneità per principianti
- 15/100
- Tipo di issue
- Bug
- Chiarezza
- Da chiarire
- Stato di attività
- Attiva
- Ambito
- backend
Direzione di ricerca
Start by running the included MWE, which compares the sparse Hessian from MOI.eval_hessian_lagrangian on MOI.Nonlinear.SparseReverseMode() with ForwardDiff.hessian, and check the entry H[4, 3] (about 1.2e-11 versus 1.2e-11 with a larger absolute error). The cause is the coloring-based Hessian recovery, not the derivative formulas. The maintainers have not chosen a fix among the three options (document, Double64 intermediates, or SparseMatrixColorings star coloring), so decide on the approach with them before writing code.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
I'm not sure this is actionable, but it also seems worth doing something about: maybe just documentation, but there are a couple of other options I'll detail below.
This came up while analyzing (with Claude's help) a standard benchmark problem, the CUTEst problem nondquar at n = 5:
(x1 - x2)^2 + (x4 - x5)^2 + Σ_{i=1}^{3} (x_i + x_{i+1} + x_5)^4
Here's the MWE to demonstrate the precision loss:
import MathOptInterface as MOI
import ForwardDiff
# MOI implementation
n = 5
x = [1.0, -1.0, 1.0, -1.0, 1e-6]
v = MOI.VariableIndex.(1:n)
obj = Expr(:call, :+, :(($(v[1]) - $(v[2]))^2), :(($(v[n-1]) - $(v[n]))^2),
(:(($(v[i]) + $(v[i+1]) + $(v[n]))^4) for i in 1:n-2)...)
model = MOI.Nonlinear.Model()
MOI.Nonlinear.set_objective(model, obj)
ev = MOI.Nonlinear.Evaluator(model, MOI.Nonlinear.SparseReverseMode(), v)
MOI.initialize(ev, [:Hess, :HessVec])
st = MOI.hessian_lagrangian_structure(ev)
vals = zeros(length(st))
MOI.eval_hessian_lagrangian(ev, vals, x, 1.0, Float64[])
H = zeros(n, n)
for ((i, j), w) in zip(st, vals)
H[i, j] += w
i == j || (H[j, i] += w)
end
# ForwardDiff implementation
f(z) = (z[1] - z[2])^2 + (z[n-1] - z[n])^2 + sum((z[i] + z[i+1] + z[n])^4 for i in 1:n-2)
Hf = ForwardDiff.hessian(f, x)
Now compare the two Hessians:
julia> H - Hf
5×5 Matrix{Float64}:
0.0 0.0 0.0 0.0 0.0
0.0 4.44089e-16 -4.3416e-17 0.0 0.0
0.0 -4.3416e-17 0.0 4.3416e-17 0.0
0.0 0.0 4.3416e-17 0.0 0.0
0.0 0.0 0.0 0.0 4.44089e-16
You might think everything is fine: errors are ~eps. But they are against a baseline of 1e-11:
julia> H[4, 3]
1.2000043416036534e-11
julia> Hf[4, 3]
1.2e-11
And that's a very large error indeed. At x = [1, -1, 1, -1, 1e-6] every inner sum equals 1e-6 exactly in floating point, so the cross partial ∂²f/∂x3∂x4 = 12·(1e-6)² = 1.2e-11; ForwardDiff's answer is the correct one.
It seems pretty clear this comes from the coloring, and because your coloring is both good and important the paths to fix this are narrow. I currently see three possible options:
- don't fix, just document
- support
Double64, if the user requests it, for intermediate storage - support SparseMatrixColorings (xref #3806), which would allow one to use star coloring
Any thoughts on what you prefer? The documentation or Double64 might be something I could try; I'd probably defer to others for SparseMatrixColorings if they'd be willing to pitch in.
- Lingua principale
- Julia
- Stelle
- 506
- Fork
- 103
- Merge medio
- 1g 10m
- PR unite (30g)
- 12
Preparare l'ambiente
Questo progetto non fornisce container di sviluppo, Dockerfile né guida per i contributori, quindi l'ambiente è a tuo carico: parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di jump-dev/MathOptInterface.jl
-
[Bridges] MultirowChange in set_map.jl drops zero coefficientsForse già presa @odow l’ha presa 6 giorni fa. Aperta
jump-dev/MathOptInterface.jl#3106 · 2 commenti · 1 assegnatario ·
I maintainer di solito rispondono entro 1 giorno
-
Layer instantiatorAperta
Difficoltà 5/5 Più di una settimana Idoneità per principianti 35/100
jump-dev/MathOptInterface.jl#2986 · 3 commenti ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 5/5 Più di una settimana Idoneità per principianti 25/100
jump-dev/MathOptInterface.jl#2969 · 2 commenti · 1 reazione ·
I maintainer di solito rispondono entro 1 giorno
-
Add Batched{S} setApertaType: Set Request
Difficoltà 5/5 Più di una settimana Idoneità per principianti 35/100
jump-dev/MathOptInterface.jl#2904 · 15 commenti · 7 reazioni ·
I maintainer di solito rispondono entro 1 giorno
-
Performance problem with deeply nested nonlinear expressionsForse già presa @blegat l’ha presa 457 giorni fa. Aperta
Difficoltà 4/5 3-5 giorni Idoneità per principianti 45/100
jump-dev/MathOptInterface.jl#3065 · 11 commenti ·
I maintainer di solito rispondono entro 1 giorno
Tutte le issue di jump-dev/MathOptInterface.jl
Issue simili
-
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 83/100
JuliaMath/Polynomials.jl#647 ·
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 74/100
OpenSourceAWE/SymbolicAWEModels.jl#431 ·
I maintainer di solito rispondono entro 1 giorno
-
Make PDAQP an optional extraAperta
Difficoltà 2/5 1-3 ore Idoneità per principianti 66/100
-
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 89/100
I maintainer di solito rispondono entro 4 giorni
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 76/100
I maintainer di solito rispondono entro 1 giorno