Oscar Dowson

Related links to the Python ecosystem using airspeed-velocity: * https://github.com/airspeed-velocity/asv * https://numpy.org/doc/stable/benchmarking.html * https://docs.scipy.org/doc/scipy/dev/contributor/benchmarking.html * https://pv.github.io/scipy-bench/

Most are expected because the underlying problem is non-convex. However, `007_020` is incorrect: ```Julia using Pavito, JuMP, GLPK, Ipopt mip_solver = MOI.OptimizerWithAttributes( GLPK.Optimizer, "msg_lev" => 0, "tol_int" => 1e-9, "tol_bnd"...

To update this, only `007_020` remains an issue: https://github.com/jump-dev/Pavito.jl/blob/820a1f029a05407f1e3f71fb040efa769f502f40/test/jump_tests.jl#L49-L62

It's plausible that there are some performance improvements that we could make. I haven't benchmarked the package closely. Ipopt is very "simple" so it also doesn't surprise me that KNITRO...

x-ref https://github.com/jump-dev/DiffOpt.jl/blob/edb31fe847afa0c96bd1f37ebb8b1c33db08786c/test/conic_program.jl#L574-L578 but there are lots of places in the tests that could be improved. We could potentially roll this into #102. No need to have lots of issues open...

@matbesancon is the exponential cone meant to work? #50 is open, and the docs mention only PSD and SOC.

Blocked by https://github.com/jump-dev/HiGHS.jl/issues/157

See https://github.com/jump-dev/DiffOpt.jl/issues/233 for a report and code that DiffOpt is much faster than alternatives. I think we need to double check what we're benchmarking and how.

Closing in favor of https://github.com/jump-dev/Gurobi.jl/issues/415. This doesn't seem to be something we can fix in SDDP.jl.

Closing in favor of https://github.com/odow/SDDP.jl/issues/496