[Rd] messing with ...
Prof Brian Ripley
ripley at stats.ox.ac.uk
Wed Aug 13 19:18:01 CEST 2008
On Wed, 13 Aug 2008, Tony Plate wrote:
> Ben Bolker wrote:
>>
>> I'm looking for advice on manipulating parameters that
>> are going to be passed through to another function.
>>
>> Specifically, I am working on my version of "mle",
>> which is a wrapper for optim (among other optimizers).
>> I would prefer not to replicate the entire argument
>> list of optim(), so I'm using ... to pass extra arguments
>> through.
>>
>> However:
>> the starting values are specified as a list,
>> which means that users can potentially specify them
>> in any order (or at least that's the way it works
>> now -- one solution to the problem I'm about to state
>> is to insist that they specify the parameters in the
>> same order as they are given in the arguments of
>> the objective function).
>> However, there are other arguments (lower, upper,
>> control$parscale, control$ndeps) that should all
>> be in the same order as the objective function
>> definition by the time they get to optim()). I can
>> think of a few solutions:
>>
>> (1) make the user specify them all in the right order (ugh)
>> (2) add all of them as explicit parameters to my function
>> so that I can rearrange them appropriately (ugh)
>> (3) mess with the ... argument before it gets passed
>> through to optim (impossible?)
>> (4) capture ... as arglist <- list(...), manipulate the arguments
>> as necessary, then pass them along to optim as
>> do.call("optim",arglist) (ugh but maybe the best solution?)
>>
>> any thoughts?
> here's my two cents:
> - require names on parameters, rather than order
> - construct calls and use eval() rather than do.call() (then you can
> manipulate list(...) without the ugh factor of do.call() -- though is
> do.call() any different to eval() in R? -- I know in S-PLUS that the use of
> do.call() can completely blow out memory usage)
do.call is just a way to construct and eval() calls. Since it is internal
C code it does it quite efficiently.
> - to avoid manually duplicating arg lists, use constructs like
> names(formals(optim)) and pmatch to find args that below to the optimizer
> function vs the objective function
Using wrappers is a better idea: you can see the idea in several places
in the base graphics code.
--
Brian D. Ripley, ripley at stats.ox.ac.uk
Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/
University of Oxford, Tel: +44 1865 272861 (self)
1 South Parks Road, +44 1865 272866 (PA)
Oxford OX1 3TG, UK Fax: +44 1865 272595
More information about the R-devel
mailing list