From ripley at stats.ox.ac.uk  Wed Aug 13 19:18:01 2008
From: ripley at stats.ox.ac.uk (Prof Brian Ripley)
Date: Wed, 13 Aug 2008 18:18:01 +0100 (BST)
Subject: [Rd] messing with ...
In-Reply-To: <48A30D60.2020304@acm.org>
References: <48A3019E.5080209@zoology.ufl.edu> <48A30D60.2020304@acm.org>
Message-ID: <alpine.LFD.1.10.0808131814070.2887@auk.stats.ox.ac.uk>

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



[Rd] messing with ...
Prof Brian Ripley