AbstractVector for list of terms in functions

[blegat]

The functions currently enforces the list of terms to be a Vector, e.g.

mutable struct ScalarAffineFunction{T} <: AbstractScalarFunction
    terms::Vector{ScalarAffineTerm{T}}
    constant::T
end

However, the fact that it is a Vector and not any AbstractVector does not help the solver wrappers in any way. Before we add the term types and we had different field for the coefficients and variables, we could have solver wrappers that pass directly the coefficient vector by pointer to the C-interface but won't do that anymore. It will need to iterate through the vector to do some transformation anyway so I suspect that if we change this to AbstractVector, it won't require any change from the solver wrappers.

The tricky point to discuss is how to update the MOIU model. We have a few choices:

1. Store only function with Vector terms and collect the terms if a function is passed with AbstractVector
2. Store a vector of an non-concrete type not specifying which type of vector is it allowing to store function using different types of vectors
3. Allow either 1) and 2) or even more by simply taking what is in the macro call. For instance if we have ScalarAffineFunction{T, VT <: AbstractVector{T}}, we could define const StandardScalarAffineFunction{T} = ScalarAffineFunction{T, Vector{T}} and use @model ... (StandardScalarAffineFunction, ...) ... to do 1) and do @model ... (ScalarAffineFunction, ...) ... to do 2).

What do you think ?

The advantages of using AbstractVector instead of Vector are numerous:

• GPU support ScalarFunctionIterator has quadratic complexity #418 (comment)
• Use views in function iterators ScalarFunctionIterator has quadratic complexity #418 (comment)
• Use StructOfArrays ScalarFunctionIterator has quadratic complexity #418 (comment)
• Implement lazy_operate lazy_operate #526

[mlubin]

Using non-concrete vector types may cause a performance hit, not to mention significant code design and readability implications.

For performance, we need to have a comprehensive benchmark suite before making a change like this.

GPU support

I don't understand this use case. Why would you need a ScalarAffineFunction with the vector terms stored on a GPU?

Use views in function iterators

The iterators could also be redesigned to return a hypothetical ScalarAffineFunctionView.

Use StructOfArrays

I didn't understand the linked comment. I, for one, would be pretty unhappy as a solver wrapper author if users are allowed to provide input using arbitrary data structures. It pushes a lot of complexity into the solver interfaces that really shouldn't be needed. I wouldn't want users complaining to me that there's a bug in the solver wrapper because it doesn't handle SomeWeirdArray. The basic problem representation in MOI needs to be as concrete and as simple as possible if we want MOI to have any potential of becoming a standard (see also MathOptFormat). </end rant>

Implement lazy_operate

This argument needs benchmarks to be convincing.

I should also note that I'm not going to consider nonessential breaking changes in MOI until after JuMP 0.19 is close to being ready to release. Every MOI version bump at this stage seems to translate into a ~1 month delay on the JuMP 0.19 release.

[blegat]

I don't understand this use case. Why would you need a ScalarAffineFunction with the vector terms stored on a GPU?

cc @mohamed82008

It pushes a lot of complexity into the solver interfaces that really shouldn't be needed.

The solver interface only uses the AbstractVector interface so the solver interface code shouldn't need any change

I should also note that I'm not going to consider nonessential breaking changes in MOI until after JuMP 0.19 is close to being ready to release.

I totally agree with this, we should add a breaking label for breaking changes

[odow]

We discussed this on April's developer call. This can be implemented in a non-breaking future release by introducing a new function type, and having something like const ScalarAffineFunction{T} = GenericScalarAffineFunction{Vector{T},T}.

Removing from 0.10 milestone and breaking.

[odow]

Closing in favor of #863 We should consider things holistically if we're going to redesign the functions.