Jump.jl: inconsistent naming with result_value/result_dual/MOI.InfeasibleNoResult

[mlubin]

JuMP uses result_value for primal results and result_dual for dual results. This can lead to confusion with MOI.InfeasibleNoResult. Coming from the JuMP side, InfeasibleNoResult could easily be interpreted as meaning that no result_value is available (https://discourse.julialang.org/t/first-alpha-release-of-jump-0-19-jump-mathoptinterface/16099/7)

Should we rename result_value to result_primal? My hesitation is that it's a bit wordier than getvalue.

@chkwon

[blegat]

It seems weird to call it result_primal while result_dual is not defined for variables.

[odow]

I haven't brought this up because I didn't want to re-open the bike shed, but I like primal_value and dual_value.

If we only want to rename result_value, I'm in favour of result_primal.

[chkwon]

I admit that I am super confused with various MOI status values. I guess the interpretation of each status would depend on each solver (or each algorithm within each solver) and each problem class. After reading slides and watching presentation videos, I see where this complexity is coming from.

That said, here are my two cents.

Many _users_ of JuMP, outside the math programming community, would just want to solve the primal problem and want to know what their action items are. Well, many of them would not care about the dual at all. Practitioners and undergraduate students may not even know/remember what dual is. I know some universities teach LP modeling and solution by solvers, as an introductory freshman course or perhaps as part of MBA programs, without teaching duality. For them, result_primal would sound strange.

I believe primal is the main output and dual is just some other side information for many, while dual is as important as or even more important than primal for some others. I'm not sure what's the best option in this sense. I actually thought get_value and get_dual are not a bad idea.

More issues on the MOI status side, rather than in result_value. Indeed, I thought MOI.InfeasibleNoResult meant no primal value to return. Infeasible part seems more important than NoResult part I guess. Can NoResult part be inferred from primal_status and dual_status?

MOI status values are difficult to interpret without knowing how solvers work. Can JuMP provide problem class specific status returns, on top of the three generic MOI returns? I was actually thinking of writing a helper package, if possible, at least for LP problems, for interpretation so that I can use it for my teaching. Maybe I should let my undergraduate students read the solver output, without telling them about MOI.

Sorry for long comments. Perhaps I am reiterating...

[odow]

It might be worth added a function like this for non-advanced users:

"""
    simple_status(model::JuMP.Model)

Return a symbol describing the status of the solution. One of
 - `:optimal`
 - `:infeasible`
 - `:unbounded`
 - `:infeasible_or_unbounded`
 - `:not_sure`
"""
function simple_status(model)
    if termination_status(model) == MOI.Success && primal_status(model) == MOI.FeasiblePoint
        return :optimal
    elseif (termination_status(model) == MOI.Success && 
            dual_status(model) == MOI.InfeasibilityCertificate) ||
        termination_status(model) == MOI.InfeasibleNoResult
        return :infeasible
    elseif termination_status(model) == MOI.Success && 
            primal_status(model) == MOI.InfeasibilityCertificate
        return :unbounded
    elseif termination_status(model) == MOI.InfeasibleOrUnbounded
        return :infeasible_or_unbounded
    else
        return :not_sure
    end
end

[odow]

MOI status values are difficult to interpret without knowing how solvers work.

This is by design. It is hard to abstract over solver status reporting when it is heavily dependent on how individual solvers work. This is particularly true since JuMP/MOI is not confined to the LP/MIP world.

At one point @juan-pablo-vielma was talking about a "JuMP Training Wheels" package that would hide a lot of the complexity for introductory teaching. Once students understand the basics, you can remove the training wheels and show then what is under the hood.

[chkwon]

MOI status values are difficult to interpret without knowing how solvers work.

This is by design. It is hard to abstract over solver status reporting when it is heavily dependent on how individual solvers work. This is particularly true since JuMP/MOI is not confined to the LP/MIP world.

I see the point. I'm glad to see the new JuMP is becoming very rich in many aspects.

At one point @juan-pablo-vielma was talking about a "JuMP Training Wheels" package that would hide a lot of the complexity for introductory teaching. Once students understand the basics, you can remove the training wheels and show then what is under the hood.

I agree with it. Perhaps we can have a package called "JuMPlite" or "SimpleJuMP" or "HoP" that implement minimal functionalities. (To unlock the regular JuMP, they need to solve 100 problems and level up... lol.. )

[chkwon]

>       return :not_sure

I love this.

[mlubin]

Enums instead of symbols, but yes this is a good idea. We can attach
documentation to the enum providing a long-form interpretation. ":optimal"
is problematic because we don't want to incorrectly declare global
optimality, but ":solved" is ok.

On Thu, Oct 11, 2018 at 3:26 PM Oscar Dowson [e-mail]
wrote:

It might be worth added a function like this for non-advanced users:

""" simple_status(model::JuMP.Model)Return a symbol describing the status of the solution. One of - :optimal - :infeasible - :unbounded - :infeasible_or_unbounded - :not_sure"""function simple_status(model)
if termination_status(model) == MOI.Success && primal_status(model) == MOI.FeasiblePoint
return :optimal
elseif (termination_status(model) == MOI.Success &&
dual_status(model) == MOI.InfeasibilityCertificate) ||
termination_status(model) == MOI.InfeasibleNoResult
return :infeasible
elseif termination_status(model) == MOI.Success &&
primal_status(model) == MOI.InfeasibilityCertificate
return :unbounded
elseif termination_status(model) == MOI.InfeasibleOrUnbounded
return :infeasible_or_unbounded
else
return :not_sure
endend

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/JuliaOpt/JuMP.jl/issues/1544#issuecomment-429087152,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABp0M21hbYnEyxUi9xZGP2YjaTzIcNkfks5uj5tLgaJpZM4XYAsZ
.

[chkwon]

There is also MOI.UnboundedNoResult. When is this used?

[blegat]

When it is unbounded but the primal status is not InfeasibilityCertificate

[mlubin]

E.g., there might not be a proof of unboundedness that fits in a primal
result. (Similar to how MIP solvers usually don't have a proof of
infeasibility to return.)

On Thu, Oct 11, 2018 at 6:36 PM Benoît Legat [e-mail]
wrote:

When it is unbounded but the primal status is not InfeasibilityCertificate

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/JuliaOpt/JuMP.jl/issues/1544#issuecomment-429143092,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABp0Mx6w_GDxHrMDReGZpHtw2DvWRxK_ks5uj8fXgaJpZM4XYAsZ
.