From ripley at stats.ox.ac.uk  Tue May 15 20:02:56 2007
From: ripley at stats.ox.ac.uk (Prof Brian Ripley)
Date: Tue, 15 May 2007 19:02:56 +0100 (BST)
Subject: [Rd] optim bug (PR#9684)
In-Reply-To: <Pine.GSO.4.56.0705150857280.20562@durian.statsci.com>
References: <20070514181124.4D9602A36F@slim.kubism.ku.dk>
	<Pine.LNX.4.64.0705150748380.12894@auk.stats>
	<Pine.GSO.4.56.0705150857280.20562@durian.statsci.com>
Message-ID: <Pine.LNX.4.64.0705151821490.909@gannet.stats.ox.ac.uk>

There quite a lot of these: optimize, uniroot, nlm for example.

I don't think the problem is large enough to merit another argument.
It is tempting to move '...' up the argument list so that partial matching 
will not occur.  I am not sure how far you can go: ?optim has positional 
matching for 'method', and ?optimize has abbreviations for lower and 
upper.

In R you rarely need to pass additional arguments in programming as 
lexical scoping can be used to capture them.

I'll do some experimenting.


On Tue, 15 May 2007, Bill Dunlap wrote:

> On Tue, 15 May 2007, Prof Brian Ripley wrote:
>
>> This is not a bug, but as documented on the help page:
>>
>>       ...: Further arguments to be passed to 'fn' and 'gr'. Beware of
>>            partial matching to earlier arguments.
>>
>> You have partial matching to 'upper'.
>
> We have this problem in optim(), integrate(),
> and probably other functions.  These functions
> have a lot of arguments before the ..., using
> up a lot of partial matching space.  Would you consider
> adding another argument to the tail end of
> their argument lists that would include the
> auxillary arguments?
>
> E.g.,
>   optim <- function(par, fn, gr = NULL,
>           method = c("Nelder-Mead", "BFGS", "CG", "L-BFGS-B", "SANN"),
>           lower = -Inf, upper = Inf,
>           control = list(), hessian = FALSE,
>           ..., aux.args = list(...))
> If the user did not supply aux.args this would
> act like the old version.  If the user did supply
> aux.args then the function could check that no
> unrecognized arguments were given to optim.
>
> optim might require 2 such arguments,
>    aux.args.fn = list(...),  aux.args.gr=aux.args.fn
> (The forces you to know that the objective function
> is called 'fn', not integrate's 'f' or apply's 'FUN'.)
> I don't know what the best name for such an argument
> would be.  If we added it, it would nice to make it
> the same in R and Splus.
>
>> On Mon, 14 May 2007, christina.merz at gmx.de wrote:
>>
>> 'optim' does not accept arguments called 'u'. Here is an example:
>>
>>> R> fun<-function(x,u) (x-u)^2
>>> R> optim(7,fn=fun,u=9)
>>>
>>> Fehler in fn(par, ...) : Argument "u" fehlt (ohne Standardwert)
>>> Zus?tzlich: Warning message:
>>> bounds can only be used with method L-BFGS-B in: optim(7, fn = fun, u = 9)
>
> ----------------------------------------------------------------------------
> Bill Dunlap
> Insightful Corporation
> bill at insightful dot com
> 360-428-8146
>
> "All statements in this message represent the opinions of the author and do
> not necessarily reflect Insightful Corporation policy or position."
>
>

-- 
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] optim bug (PR#9684)
Prof Brian Ripley