fixed parameters

[JanHasenauer]

In the branch feature_new_optimizers, we offer the possibility of fixing some parameters. Currently, this "option" is provided by PestoOptions. As PestoOptions is however not provided to routines such as getParameterConfidenceIntervals, I would suggest to include the information in the parameters struct. It anyhow concerns the parameters.

[JanHasenauer]

I think the a good approach to handle fixed parameters should avoid to modification of all of PESTO's core functions. Currently, it is implemented really on the lowest level, see e.g. performOptimizationFmincon.m. This generates a lot of addition code, decreases the readability, and makes it more difficult to implement external libraries.

I would suggest to implement on the highest levels, e.g. in 'getMultiStarts.m' and 'getParameterProfiles.m', a reduction of the problem. In a first step, the problem could be reduced to a problem without fixed parameters. In a second step, the calculations can be performed for this reduced problem. Finally, in a third step, the parameter struct for the full problem could be generated. This approach would allow us to keep the actually calculations routine simple.

Would du you think about the approach?

To support it, I implemented already the rather simple function 'getReducedProblem.m' and 'getFullParameterStruct.m' for step 1 and 3.

[FFroehlich]

I agree, specifying fixed parameters at the level of parameter struct makes sense. I also agree that computing an accordingly reduced version of the parameter struct should reduce overall code complexity.

[paulstapor]

Well, new features mean always more code somehow. So the question is how to have the lowest increase of code complexity, I think...

I would suggest to implement on the highest levels, e.g. in 'getMultiStarts.m' and 'getParameterProfiles.m', a reduction of the problem...

I agree, that it is better to have the idea of 'getFullParameterStruct.m' outside of the core optimization routines, like performOptimizationFmincon().

One problem remains: The objective wrapper needs to know about fixed parameters, since it deals with an objective function, which does not know about them. But so far, the objective wrapper does not see the parameters struct... This could however be solved by using the function setObjectiveWrapper(). When this wrapper is set, one could simply use parameters.fixed and parameters.fixedValues instead of the according options, for example.

[JanHasenauer]

I just committed two routines getReducedProblem.m and getFullParameterStruct.m. The former constructs a reduced problem without fixed parameters, the latter constructs from the solution to the reduced problem the full problem.

The code can be used as follows: `% Construct problem without fixed parameters [reduced_parameters,reduced_nll_function,reduced_options] = getReducedProblem(parameters,nll_function,options);

% Run multi-start optimization for problem without fixed parameters [reduced_parameters,fh.MS] = getMultiStarts(reduced_parameters,reduced_nll_function,reduced_options);

% Run profile calculation for problem without fixed parameters [reduced_parameters,fh.PL] = getParameterProfiles(reduced_parameters,reduced_nll_function,reduced_options);

% Construct full problem [parameters] = getFullParameterStruct(parameters,reduced_parameters,options,'profile');`

Conceptually, it can be extended to sampling and so on.

If we insert the respective functions at the beginning / end of the high-level routines, I think we should be able to leave the low-level code completely unchanged. Also, the objective function wrapper would not need to account for the fixed parameters, as a reduced problem is constructed. It appears that this approach is is more easy to modularise than including it in the objective function wrapper.

I'm looking forward to your comments.