Unable to specify `idxs` on `PLProblem` (problem when checking correct `profile_range`

[TorkelE]

So here is the situation. I have a model with many parameters > 20. Most are irrelevant, and I only wish to profile like 3 of them. Now there are two methods for this:

1. For each parameter I wish to profile: - Create a PLProblem with a single profile_range corresponding to the range of interest for this parameter. - Run profile, selecting that parameter's index only.
2. In a single round: - Create a PLProblem with a an array of profile_range, one for each parameter. This includes creating dummy ranges for the parameters I am not interested in. - Run profile, selecting the indices of my parameters of interest only.

The problem with (2) is that I need to create dummy profiles for all parameters I am not interested. More critically, I have to actually check their initial values so that they are within these dummy ranges. The problem with (1) is that if (and this will most likely happen) one of all those parameters I am not interested in is not within the range of the profile_range I designate for one of my parameters of interest, there will be an error when I try to create my PLProblem.

The required workflow is thus to ave a loop where I go through all my parameters, manually checking if which set they are in, and then either fetches the appropriate profile range, or computes a dummy range from itsvalues.

I am not sure what the best way to solve this is, but it feels like there is room for improvement. One wat would be to allow the designation of idxs in PLProblem.

[ivborissov]

Hm, that’s something I’ve considered but haven’t found a good solution for yet. The options I see are:

• Remove profile_range and rely solely on (lb, ub) from OptimizationProblem. This would simplify things, as meaningful values for profiling parameters can be set directly within OptimizationProblem. However, it would also introduce an artificial limitation, restricting us to box constraints—something not all solvers support.
• Move both idxs and profile_range to the same interface level (either PLProblem or profile) and enforce that they have the same length. The key idea here is that profile_range should only be set for idxs, not for all parameters. I’m not sure if this intuition is clear enough.

@sumiya11 @TorkelE If you have any ideas on how to make it more user-friendly and intuitive, let me know.

[TorkelE]

I agree that removing profile_range for relying on lb and ub seems unideal. (i.e. in my case I solve the initial OptimizationProblem with an unbounded optimiser, so I would have to create a new OptimizationProblem to pass to likelihood profiler). And it is also nice to tune be able to tune the range separately from when I do the optimisation.

Some version of the second one seems doable, but I admittedly haven't really thought it through that much yet.

Nothing that requires a quick fix though (e.g. I have it working around this on my computer, and others should be able to as well), so better to take the time to get it right.

[ivborissov]

Sorry for the delay in addressing this. After considering different solutions, I believe the simplest and most practical solution is to allow (-Inf, Inf) or nothing values in profile_range at the PLProblem level, and to perform validation only at the profile() level for the parameters actually listed in idxs. This seems to balance between keeping PLProblem complete and defined and allowing some flexibility by removing the need to specify dummy ranges. @TorkelE What do you think — will it make the interface more friendly?

[TorkelE]

Nothing potentially sounds like a good idea. Travelling and on my phone now though, so can have a proper look at it in a week. But as I remember things using nothing should be a good idea.

[ivborissov]

Good! Will implement it shortly and hope it makes things better