You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
With the addition of DoubleDict that maps pairs (F, S) to a container parametrized by F and S, we could create a struct VectorOfConstraints designed to hold a list of constraints as Vector{Tuple{F, S}} and efficiently handle modifications, deletion, additions, ...
Then UniversalFallback would hold a DoubleDict with a VectorOfConstraints for each constraint type and MOIU.AbstractModel would have different fields holding with VectorOfConstraints for each constraint type so that accessing the right struct is type-stable.
This has the advantages of:
make Utilities/model.jl more readable as part of the code will be moved to the definition of this struct.
share code between Utilities/model.jl and Utilities/universal_fallback.jl
More efficient UniversalFallback
It will have the effect that MOIU.AbstractModel may have clashes of indices between different constraint types but this is already the case for UniversalFallback and shouldn't be breaking.
This also open the possibility to have a tighter integration with MatrixOptInterface. MatrixOptInterface could define a MatrixOfConstraints that hold a list of constraints of the same type storing the list of coefficients in a big sparse matrix (which is similar to concatenating all the constrints in a big VectorAffineFunction-in-(cartesian product of the sets). Then holding these MatrixOfConstraints in UniversalFallback and MOIU.AbstractModel instead of the VectorOfConstraints would effectively create models similar to the matrix forms in MatrixOptInterface.
The text was updated successfully, but these errors were encountered:
With the addition of
DoubleDict
that maps pairs(F, S)
to a container parametrized byF
andS
, we could create astruct VectorOfConstraints
designed to hold a list of constraints asVector{Tuple{F, S}}
and efficiently handle modifications, deletion, additions, ...Then
UniversalFallback
would hold aDoubleDict
with aVectorOfConstraints
for each constraint type andMOIU.AbstractModel
would have different fields holding withVectorOfConstraints
for each constraint type so that accessing the right struct is type-stable.This has the advantages of:
Utilities/model.jl
more readable as part of the code will be moved to the definition of this struct.Utilities/model.jl
andUtilities/universal_fallback.jl
UniversalFallback
It will have the effect that
MOIU.AbstractModel
may have clashes of indices between different constraint types but this is already the case forUniversalFallback
and shouldn't be breaking.This also open the possibility to have a tighter integration with MatrixOptInterface. MatrixOptInterface could define a
MatrixOfConstraints
that hold a list of constraints of the same type storing the list of coefficients in a big sparse matrix (which is similar to concatenating all the constrints in a bigVectorAffineFunction
-in-(cartesian product of the sets). Then holding theseMatrixOfConstraints
inUniversalFallback
andMOIU.AbstractModel
instead of theVectorOfConstraints
would effectively create models similar to the matrix forms in MatrixOptInterface.The text was updated successfully, but these errors were encountered: