Better return type for mode estimation

[mhauru]

The Optim.jl interface returns a ModeResult, a type we define for holding the outcome of the optimisation. For compatibility the Optimisation.jl interface currently returns the same type, but it's not quite a natural fit for it. We might consider changing the return type before making the switch of interfaces official and possibly deprecating the Optim.jl one. Might also consider aligning with similar types from SciML.

This came up in review of #2221 with @torfjelde, https://github.com/TuringLang/Turing.jl/pull/2221/files#r1608363430.

[ElOceanografo]

Out of curiosity, besides the type of the parameter vector (#2363), what other features or changes would you want for the new and improved return type?

[mhauru]

One thing I was dissatisfied with was the awkward nesting of data about the optimisation, and some commonly needed things being hard to access. For instance, the value of the objective function is stored three times: in -result.lp, in result.optim_result.objective, and, if OptimJL was used as the backend, in result.optim_result.original.minimum. However, something like convergence information, which is often of great interest, I think is only accessible through result.optim_result.original.

I'm not sure what the best thing to do is for intuitive usability, while keeping all the data reported by Optimization.jl and the backend optimiser accessible to users who know what they are doing. Maybe just storing the thing returned by Optimization.jl and writing getter functions to get the often-needed bits from it?

Also, we should store a flag for whether this was MLE or MAP, and maybe also the model object.

The current return type is a left-over from the time when the only optimiser we supported was Optim.jl, and life was simpler.

[ElOceanografo]

Thanks, that makes sense. As an end-user, my main complaint about usability is the one in #2363, and the current structure seems basically fine to me. A MAP/MLE flag would be good. The model object is already stored in result.f.model, so maybe it just needs a getter function...in general, writing some well-documented getter functions seems like an easy way to improve usability.

Thinking about it as an end-user, the main things I want to be able to get easily from a mode estimate, whether as fields or from getter functions:

• Parameter estimates, accessible by name (a dimension or nparameters getter function would be nice)
• Objective/log-probability value
• Objective function, to do diagnostics, likelihood profiling, etc.
• Optimization.jl results, to drill down into as needed
• What algorithm was used
• MAP vs. MLE
• Coefficient table/standard errors

[ElOceanografo]

One more wish to add to the list: it would be great if there was a way to get generated_quantities from ModeResults!

[torfjelde]

One more wish to add to the list: it would be great if there was a way to get generated_quantities from ModeResults!

This will be trivial if we take the VarNamedVector approach @mhauru :)