Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Large update for MathOptInterface v1.0 #2

Merged
merged 12 commits into from
Jan 9, 2023
Merged

Large update for MathOptInterface v1.0 #2

merged 12 commits into from
Jan 9, 2023

Conversation

odow
Copy link
Member

@odow odow commented Jan 6, 2023

This is a large update for changes in MOI v1.0. It requires a local fork of MOI to work.

This is a large update for changes in MOI v1.0. It requires a local
fork of MOI to work.
odow added a commit to jump-dev/JuMP.jl that referenced this pull request Jan 6, 2023
To be read in conjunction with jump-dev/MathOptInterface.jl#2070

A proof-of-concept solver and JuMP examples are available at jump-dev/MultiObjectiveAlgorithms.jl#2

The issue #2099 discussed two approaches
for implementing MO in JuMP.

 1. Treat multicriteria as a vector of scalar objectives and a vector of
    scalar senses. This would let someone write [Min, Max], [f(x), g(x)].
    The main reason for this approach is that it matches what users want
    to do.
 2. Treat multicriteria as an optimization problem with a vector-valued
    objective function. Users could write only Min, f(x) where f(x) is a
    vector. The main reason for this approach is that it matches what
    MathOptInterface wants.

This PR implements option 2. The strongest reason in support of option 2
is that it requires very little code to implement, suggesting that it is
a natural extension of MOI.

The biggest downside is that it doesn't overcome the Min-Max issue; but
I think we can work around this with user-facing cosmetic tooling in JuMP;
solvers would be forced to accept a single sense.
@codecov-commenter
Copy link

codecov-commenter commented Jan 6, 2023

Codecov Report

Merging #2 (a324d89) into master (5f15203) will increase coverage by 5.08%.
The diff coverage is 85.27%.

@@            Coverage Diff             @@
##           master       #2      +/-   ##
==========================================
+ Coverage   82.41%   87.50%   +5.08%     
==========================================
  Files           3        2       -1     
  Lines          91      152      +61     
==========================================
+ Hits           75      133      +58     
- Misses         16       19       +3     
Impacted Files Coverage Δ
src/MOO.jl 85.00% <84.84%> (-15.00%) ⬇️
src/algorithms/nise.jl 92.30% <86.66%> (+9.38%) ⬆️

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

@odow odow merged commit a8b2d85 into master Jan 9, 2023
@odow odow deleted the od/update branch January 9, 2023 23:05
odow added a commit to jump-dev/JuMP.jl that referenced this pull request Jan 25, 2023
To be read in conjunction with jump-dev/MathOptInterface.jl#2070

A proof-of-concept solver and JuMP examples are available at jump-dev/MultiObjectiveAlgorithms.jl#2

The issue #2099 discussed two approaches
for implementing MO in JuMP.

 1. Treat multicriteria as a vector of scalar objectives and a vector of
    scalar senses. This would let someone write [Min, Max], [f(x), g(x)].
    The main reason for this approach is that it matches what users want
    to do.
 2. Treat multicriteria as an optimization problem with a vector-valued
    objective function. Users could write only Min, f(x) where f(x) is a
    vector. The main reason for this approach is that it matches what
    MathOptInterface wants.

This PR implements option 2. The strongest reason in support of option 2
is that it requires very little code to implement, suggesting that it is
a natural extension of MOI.

The biggest downside is that it doesn't overcome the Min-Max issue; but
I think we can work around this with user-facing cosmetic tooling in JuMP;
solvers would be forced to accept a single sense.
odow added a commit to jump-dev/JuMP.jl that referenced this pull request Feb 10, 2023
To be read in conjunction with jump-dev/MathOptInterface.jl#2070

A proof-of-concept solver and JuMP examples are available at jump-dev/MultiObjectiveAlgorithms.jl#2

The issue #2099 discussed two approaches
for implementing MO in JuMP.

 1. Treat multicriteria as a vector of scalar objectives and a vector of
    scalar senses. This would let someone write [Min, Max], [f(x), g(x)].
    The main reason for this approach is that it matches what users want
    to do.
 2. Treat multicriteria as an optimization problem with a vector-valued
    objective function. Users could write only Min, f(x) where f(x) is a
    vector. The main reason for this approach is that it matches what
    MathOptInterface wants.

This PR implements option 2. The strongest reason in support of option 2
is that it requires very little code to implement, suggesting that it is
a natural extension of MOI.

The biggest downside is that it doesn't overcome the Min-Max issue; but
I think we can work around this with user-facing cosmetic tooling in JuMP;
solvers would be forced to accept a single sense.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

2 participants