Miles Lubin
Miles Lubin
This is mostly covered by https://github.com/JuliaOpt/JuMP.jl/pull/1223 except for duals and deciding what to do about incremental solves.
Duals are working. The only remaining issue is re-implementing fast resolves which I'll drop from the 0.19 milestone. Under 0.18 and prior, if *only* parameter values changed between solves, then...
Dropping this from the 1.0 milestone. I've yet to see anyone who has said that they care and have benefited from fast NLP resolves.
I was convinced by @trulsf's JuMP-dev talk (https://www.youtube.com/watch?v=JQ6_LZfYRqg) that this functionality should ideally be incorporated into JuMP.
Not really, travis runs on shared VMs so it will be hard to get consistent results.
Ping @jrevels, JuMP would benefit a lot from this
@pkofod, there was never any substantial effort put into this
It was a request for better syntax. The right way to go about it would be to have a separate Julia package that provides strongly typed integers (e.g., https://embeddedartistry.com/blog/2018/04/23/namedtype-the-easy-way-to-use-strong-types-in-c/) and...
That's most of the way there, but I'd also expect typed integers to be as fast as integers. In the example above, `Items(1)` is treated like a key in a...
The hang is apparently inside JuMP code, but doesn't occur when another solver like Ipopt is used. Pretty strange.