Added member types to *Change struct docstrings

[BenChung]

I've been using raw MOI to solve an optimization problem with problem modification, and I regularly need to remind myself what the types of the change struct fields are. This PR adds type information to docstrings that did not previously indicate what the type of the fields are, so that it's easy to tell what they take from Julia's help system.

[odow]

I've been using raw MOI to solve an optimization problem with problem modification

Really!?! Which solvers? What are your thoughts? Do you have a view on #360?

[codecov-io]

Codecov Report

Merging #386 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master     #386   +/-   ##
=======================================
  Coverage   96.34%   96.34%           
=======================================
  Files          40       40           
  Lines        4898     4898           
=======================================
  Hits         4719     4719           
  Misses        179      179

Impacted Files	Coverage Δ
src/functions.jl	100% <ø> (ø)	⬆️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update dcc5ebb...21b6e15. Read the comment docs.

[BenChung]

@odow I've been using MOSEK. Modulo some easy-to-fix bugs I ran into in their MOI implementation for problem modification, it's been working great. Sadly, I wrote it for 0.2, and am instead reimplementing it in JuMP 0.19 because I want to change some details and don't want to do all the thinky work for changing everything to the (wonderful) new 0.3 syntax for VectorAffineFunctions and ScalarAffineFunctions. The perils of developing code against pre-prerelease libraries! If interested, my earlier code can be found here; I apologise for the nastiness.

With regard to #360, I like the proposal generally, but share reservations about transformconstraint! becoming modify!. The semantics for modifying the same set vs. using a different set are sufficiently different to justify splitting the API up in my opinion. I'd go so far as to suggest that the transformconstraint! equivalent should not handle the case where the old set is the same as the new one at all (instead throwing an error suggesting that you use modify!). This would clearly separate the two potential semantics for transformconstraint!.

[odow]

Modulo some easy-to-fix bugs I ran into in their MOI implementation

I would expect that there a number of bugs in all of the solver wrappers.

The perils of developing code against pre-prerelease libraries!

Your code is probably the most complex usage of MOI yet! We'd love to hear any and all gripes and complaints you have with the API.

I'd go so far as to suggest that the transformconstraint! equivalent should not handle the case where the old set is the same as the new one at all

Yes, this is what we do in LinQuadOptInterface.

p.s., super late notice, but are you aware of http://www.juliaopt.org/meetings/bordeaux2018/

[BenChung]

We'd love to hear any and all gripes and complaints you have with the API.

The new function definitions in 0.3 fixed my real issue. The old API required a lot of clever indexing for VectorAffineFunctions in particular, but with the explicit structs it's a lot nicer. While I haven't ported my problem forward yet, I'm expecting it to be much easier to read at the very least! With 0.2, I've spent a long time picking apart VectorAffineFunctions to figure out what I intended them to do and how precisely the index acrobatics achieves this. The one thing that I would like though is some way to change the entire VectorAffineFunction matrix in one go, but this is a convenience that I suspect doesn't map down to the solver well.

p.s., super late notice, but are you aware of http://www.juliaopt.org/meetings/bordeaux2018/

I am! Unfortunately, while I'll be in Europe at that time, I'm busy that week. If it comes back to MIT I'd love to attend though :).

[odow]

The one thing that I would like though is some way to change the entire VectorAffineFunction matrix in one go

If you're changing the sparsity pattern, the correct way to do this is probably to delete the constraint and add a new one. If you're keeping the same sparsity pattern it shouldn't be too hard to write a wrapper that loops through calling MultirowChange on the variables.

[mlubin]

Thanks and glad to hear you like the recent changes!