Skip to content
This repository has been archived by the owner on Sep 10, 2019. It is now read-only.

[RFC] Universal Fallback : making standalone instances support everything #84

Open
blegat opened this issue Feb 7, 2018 · 1 comment

Comments

@blegat
Copy link
Member

blegat commented Feb 7, 2018

As discussed in jump-dev/JuMP.jl#1152 and in #56 (comment), we should have something that helps instance-without-optimize! support arbitrary constraints, let's call it UniversalFallback.
It can be a lot simpler than bridges since UniversalFallback will not implement optimize! so whatever is the internal instance, optimize! will not be called. This means that the internal instance does not have to contain the full instance, part of the constraints (e.g. the one that it does not support) can be stored outside without the need to transform them into supported constraints as it is the case with bridges.
It could be like

struct UniversalFallback{IT}
    instance::IT
    constraints::Dict{Tuple{DataType, DataType}, Vector}
    attributes::Dict{AbstractInstanceAttribute}
    varattr::Dict{AbstractVariableAttribute, Dict{MOI.VariableIndex}}
    conattr::Dict{AbstracConstraintAttribute, Dict{MOI.ConstraintIndex}}
end

For every MOI functions, the universal fallback try to see if instance supports it. If it does not, it stores it in its dictionaries. The performance of the different ways to store it has be analysed by @rdeits in jump-dev/JuMP.jl#1152

The advantage of the UniversalFallback is that it allows an instance to still support every possible attributes and constraints while still making sure that the most important ones are as efficient as they could be.

I am open to bikeshedding on the name UniversalFallback :-P

Note : it fixes #61

@mlubin
Copy link
Member

mlubin commented Feb 8, 2018

Sounds good to me. This is much better than using bridges. There's obviously a lot of room for benchmarking, but I'd be okay with just a solution that works for now. The abstractions won't change so we can always improve the data structure later.

This was referenced Feb 8, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants