What are the default keyword arguments for Optimization.solve shown here?
Can anyone point out to that code in Github?
1 Like
Not an Optimization.jl developer, but I assume if not set, they default to the solver’s choice, so it will vary depending on the solver you choose.
1 Like
I see. I think if Optimization.jl aims to be a consistent interface for numerical optimizers, perhaps it should provide the same default values for common parameters used by all back ends.
Different solvers implement different algorithms, so there isn’t one set of values would work by default for every solver.
1 Like
Arguments that have shared meaning get bubbled up to a higher level to be the common keyword arguments, such as with maxiters and tolerances. Those are then made to default similarly across the interface. However, arguments that are solver-specific are then defaulted specifically for the solvers. This of course is the same scheme throughout SciML. Optimization.jl is just orders of magnitude less developed than some other pieces, so it doesn’t have that many common args at this point.
I think the point was that two algorithms can both have a maxiters argument, but a common default value of 1000 doesn’t make sense.
There is a sensible default, and that is to use a tolerance-based stopping criteria if the algorithm allows for it, or require maxiters. And that’s how the maxiters argument works.
1 Like
So we can expect common defaults at some point in the future?
For anything that’s a common argument, yes. It’s an interface break if that’s the case.
1 Like
What is the mathematical definition of abstol and reltol? How do you set a reasonable common tolerance across solvers?
The only two common options that are (mostly) unambiguous across solvers are time limits and verbosity, which is why JuMP has TimeLimitSec and Silent as options. Even time limits have a number of non-trival differences in the implementation between solvers.