Oscar Dowson
Oscar Dowson
This is actually less obvious than it seems. As one problem, we're already calling a `SuiteSparse` method: ```julia julia> Q 2×2 SparseArrays.SparseMatrixCSC{Float64, Int64} with 4 stored entries: 2.0 -2.0 -2.0...
Thoughts on this? https://github.com/jump-dev/MathOptInterface.jl/pull/2300
Is there any benchmark we could run that would show this is meaningful? No one has complained about it, and I don't recall it ever appearing in our profiling, so...
> Now, for conic solvers, this is still negligible compared to the solve time so you won't see complaints, it's mostly when benchmarking to model creation time This seems like...
> I'm very hesitant to add more complexity to MOI to chase performance wins. I still believe this, and I'm tempted to close this issue because of it. I don't...
Is there still motivation for this? I think the conclusion from https://github.com/jump-dev/JuMP.jl/pull/3191 was that we should allow JuMP to pass things other than `Float64`.
Closing because I don't think there's much we can do here. The solution is to ask the user for the linear solver and path, rather than testing to see if...
1. If you're using Ipopt, you don't need POI. Syntax is the same. 2. Yes, we could support `MOI.ScalarNonlinearFunction`. The issue is that we can't rewrite `NLPBlock`.
> but this performance issue could be hit in cases where a quadratic expression is the desired typed. Exactly. Which is why this `@nl` is opt-in. We want to default...
Yeah I have no strong opinions on the name. I don't like `@nl(...)`. `@nonlinear` could work.