Forum: developers

RE: maxControl(): which arguments? [ Reply ]
By: Arne Henningsen on 2015-09-27 06:10

You wrote:
> Right. Maybe to move _all_ new parameters over to the control
> list, and advertise only that in the documentation? I think even if
> we retain the old API we can only briefly mention it in the
> documentation.

Yes, good idea!

> There are still a number of controls that are not really
> optimizer-related: finalHessian, constraints, bhhhHessian,
> fixed, possibly some more. I would not include these in the
> control structure. Or what do you think?

Yes, I agree.

> Sure, will install r-devel and do checks there, but will try to
> get the basics right first.

Good :-)

RE: maxControl(): which arguments? [ Reply ]
By: Ott Toomet on 2015-09-19 21:57

[forum:42563]

Right. Maybe to move _all_ new parameters over to the control list, and advertise only that in the documentation? I think even if we retain the old API we can only briefly mention it in the documentation.

There are still a number of controls that are not really optimizer-related: finalHessian, constraints, bhhhHessian, fixed, possibly some more. I would not include these in the control structure. Or what do you think?

Sure, will install r-devel and do checks there, but will try to get the basics right first.

RE: maxControl(): which arguments? [ Reply ]
By: Arne Henningsen on 2015-09-19 05:01

[forum:42561]

Hi Ott!

Sounds like a very well designed user interface :-)

I am indeed not sure about whether it is desirable to permit only part of the parameters to be submitted openly. It may confuse users if some arguments may be submitted openly and others may not be submitted openly. It may also confuse users if their log-likelihood function does not work, because one of its arguments is identical to one (perhaps rarely used) control parameter of a max* function. What do you suggest?

Please check the package with R-devel and the option "--as-cran" and add some missing NAMESPACE commands. Thanks!

Best wishes,
Arne

RE: maxControl(): which arguments? [ Reply ]
By: Ott Toomet on 2015-09-19 02:11

[forum:42560]

Hey Arne,

I solved the default values problem in this way:
* created a class 'MaxControl' that includes all (well, only part for now) control parameters and does the corresponding consistency checks.
* the non-user functions (like max**Compute) only accept the MaxControl structure.
* user functions accept either a list (like control=list(iterlim=100)), or a MaxControl structure, or submitting the parameters openly, in the old way.
** parameters submitted in a list or openly overwrite the corresponding defaults.
** if the user submits a MaxControl structure, it will be taken as-is and no effort is exerted to insert some sort of other defaults there.
** the user is typically supposed to submit the list, not structure, but the option the submit the structure is there to ensure that exactly the same parameters are submitted in case it is desired.
* max** functions also return the MaxControl structure.

What do you think?

I still don't understand whether you think it is desirable to permit only part of the parameters to be submitted openly..

All the tests and R CMD check work but I have to check documentation, consistency, etc.

Cheers,
Ott

RE: maxControl(): which arguments? [ Reply ] By: Ott Toomet on 2015-09-07 17:57	[forum:42523]
Arne, I agree with your concern about the default parameters. Have to think how to solve it. The last point I cannot understand: Do you suggest: * not to include any new control (including qac) directly? * include everything directly?

RE: maxControl(): which arguments? [ Reply ]
By: Arne Henningsen on 2015-09-07 08:51

[forum:42522]

Good ideas: here are my responses:

> maxControl should be part of all optimizers and wrappers
> we support, including maxLik.

Yes.

However, we need to take into account that the default values of some arguments (e.g. maximum number of iterations) should depend on the chosen optimization algorithm. Hence, maxControl() should either not set default values or it needs to know the optimization algorithm. In the first case, i.e. if maxControl() just creates a list of all specified parameters, while the maxXXX() functions set non-specified arguments to their default values, we perhaps do not need maxControl and we can just have:

maxLik <- function( fn, <some other arguments>, control=list(), ... )

> It supports _all_ parameters for all optimizers, plus other
> controls like print.level, constraints, etc., but not the very
> basic controls 'fn', 'grad', 'hess', 'start', 'fixed'. (Better to
> support less initially and add more later to preserve API.)

Yes.

> all the existing controls can also be submitted as separate
> arguments, like maxLik(fn, control=maxControl(...), tol=1e-4).
> In this case the separate argument "tol" takes precedence
> over the one submitted in maxControl. This is to preserve
> API compatibility, and to make important arguments easier
> to supply.

Yes.

> About the new arguments: I propose that while maxControl()
> supports all of them, one can directly supply only the most
> important ones. For instance, in case of Quadratic
> Approximation Correction, one can support 'qac="marquardt"'
> directly but the method specific parameters 'lambda0',
> 'lambdaStep', 'maxLambda' only through maxControl().
> This lowers the number of reserved arguments that cannot
> be supplied to the objective function. This will only break the
> API of the development version at r-forge.

I am less sure about this. When we define

maxLik <- function( fn, <some other arguments>, control=maxControl(...), ... )

all additional arguments are passed through maxControl() so we would not need to 'repeat ourselves', i.e. we do not need to have quite some arguments both in maxXXX() and in maxControl(). However, I am afraid that this makes it more complicated to pass additional parameters to the log-likelihood function and its first and second derivatives (fn, grad, hess).

maxControl(): which arguments? [ Reply ]
By: Ott Toomet on 2015-09-06 18:37

[forum:42513]

I am implementing maxControl(...) argument for max* functions. It will support a comprehensive list with all arguments for all optimizers + other controls.

I would like to hear your opinion about the following:
* maxControl should be part of all optimizers and wrappers we support, including maxLik.
* It supports _all_ parameters for all optimizers, plus other controls like print.level, constraints, etc., but not the very basic controls 'fn', 'grad', 'hess', 'start', 'fixed'. (Better to support less initially and add more later to preserve API.)
* all the existing controls can also be submitted as separate arguments, like maxLik(fn, control=maxControl(...), tol=1e-4). In this case the separate argument "tol" takes precedence over the one submitted in maxControl. This is to preserve API compatibility, and to make important arguments easier to supply.
* About the new arguments: I propose that while maxControl() supports all of them, one can directly supply only the most important ones. For instance, in case of Quadratic Approximation Correction, one can support 'qac="marquardt"' directly but the method specific parameters 'lambda0', 'lambdaStep', 'maxLambda' only through maxControl(). This lowers the number of reserved arguments that cannot be supplied to the objective function. This will only break the API of the development version at r-forge.

What do you think?
Ott