Define operate and refactor moivcat #455
Conversation
Codecov Report
@@ Coverage Diff @@
## master #455 +/- ##
==========================================
- Coverage 95.24% 94.54% -0.71%
==========================================
Files 42 44 +2
Lines 4960 5423 +463
==========================================
+ Hits 4724 5127 +403
- Misses 236 296 +60
Continue to review full report at Codecov.
|
|
Ready for review, I am not planning to do any more changes :) |
There was a problem hiding this comment.
High level comment. This makes me think that we should instead implement the standard Julia operators for the MOI types. It's pretty roundabout to say MOIU.operate(vcat, T, a, b, c) instead of T[a; b; c] given that Julia has the syntax. What's the argument for creating our own operator and type promotion system?
src/Utilities/functions.jl
Outdated
| @@ -164,6 +165,9 @@ function Base.getindex(it::ScalarFunctionIterator{<:VQF}, i::Integer) | |||
| return SQF(lin, quad, it.f.constants[i]) | |||
| end | |||
|
|
|||
| function Base.getindex(it::ScalarFunctionIterator{VVF}, I::AbstractVector) | |||
| return VVF(it.f.variables[I]) | |||
There was a problem hiding this comment.
I don't think the abbreviation VVF helps readability here.
We want When doing In MOI we do not care too much about being super-user friendly (user friendly is enough).
|
|
As a second thought, it would indeed be nice to also define |
I wonder if using a macro to switch the context could be useful. Like |
Bridges need to do some arithmetic operations like
vcat,+,-, ... and need to be able to determine the result of such operation to determine which constraints the bridge generate at compile time.To achieve this, this PR suggest to define
operate(op::Function, ::Type{T}, args...) that does the operationop(args...)with coefficient typeTandpromote_operationthat gives the type of the output the functionoperate` without the need for Julia's inference system.Currently most bridges only work when the function is
VectorAffineFunctionand convertVectorOfVariablestoVectorAffineFunctionwhile they could also work withVectorQuadraticFunctionand keepVectorAffineFunctionunconverted would allow the bridge to createVectorAffineFunctionfunctions which could be handled more efficiently by the solver.Using these functions instead of hardcoding the operations for
VectorAffineFunctionwould allow to easily build bridges that work for anyAbstractVectorFunctionas input (just like SplitIntervalBridge currently).