Open TorkelE opened 5 months ago
Thanks for bringing this to our attention. Yes, it is natural to allow scan_bounds
to be identical with theta_bounds
, however we have seen certain use-cases, where it led to unexpected results due to the differences in the way scan_bounds
are introduced in LikelihoodProfiler
code and the way bounds
(theta_bounds
) are interpreted in NLopt
. This question is part of a more general one: rewriting augmented loss function and moving away from NLopt
to Optimization.jl
.
Got it.
Yes, I think that if we could simply pass SciML's OptimizationFunction
(or OptimizationProblem
) into get_interval
that would be very useful. E.g. stuff like theta_bounds
is already defined there, and SciML/Optimization algorithms would be easier to use.
One could also pass a OptimizationSolution
as the starting point.
I think it could produce a really neat interface in the end, but yes, it also requires some work to carry out the changes.
I am trying to perform likelihood profiling for a problem from parameter fitting to data. Here, I know bounds for all parameters, and want to incorporate this both into
theta_bounds
andscan_bounds
. Turns out that ifscan_bounds
is identical to the bounds for that parameter intheta_bounds
you get an error. Wouldn't it be natural to allow this?In practice this is solvable by making
scan_bounds
ever so slightly narrower on both sides (and maybe this can be done internally if thus turns out to be the case).Just a thought, that this might be a nice improvement to make.
Minimal example:
gives: