> -----Original Message-----
> From: r-devel-boun...@r-project.org
> [mailto:r-devel-boun...@r-project.org] On Behalf Of Charles Geyer
> Sent: Monday, September 07, 2009 1:39 PM
> To: r-devel@r-project.org
> Subject: Re: [Rd] question about ... passed to two different functions
>
> Many thanks to those (Martin Morgan, Duncan Murdoch) who
> tried to straighten
> me out on ... arguments. It didn't work until I accidentally
> made two examples
> I thought were the same but one worked and the other didn't.
> Finally I
> achieved enlightenment. The following section has been added to the
> help page for the metrop function and will appear on CRAN
> when I get finished
> with the simulated tempering function.
>
> \section{Warning}{
> If \code{outfun} is missing or not a function, then the log
> unnormalized
> density can be defined without a \ldots argument and that works fine.
> One can define it starting \code{ludfun <- function(state)}
> and that works
> or \code{ludfun <- function(state, foo, bar)}, where
> \code{foo} and \code{bar}
> are supplied as additional arguments to \code{metrop}.
>
> If \code{outfun} is a function, then both it and the log unnormalized
> density function can be defined without \ldots arguments \emph{if they
> have exactly the same arguments list} and that works fine.
> Otherwise it
> doesn't work. Start the definitions \code{ludfun <-
> function(state, foo)}
> and \code{outfun <- function(state, bar)} and you get an error about
> unused arguments. Instead start the definitions
> \code{ludfun <- function(state, foo, \ldots)}
> and \code{outfun <- function(state, bar, \ldots)}, supply
> \code{foo} and \code{bar} as additional arguments to \code{metrop},
> and that works fine.
>
> In short, the log unnormalized density function and \code{outfun} need
> to have \ldots in their arguments list to be safe. Sometimes it works
> when \ldots is left out and sometimes it doesn't.
>
> Of course, one can avoid this whole issue by always defining the log
> unnormalized density function and \code{outfun} to have only
> one argument
> \code{state} and use global variables (objects in the R
> global environment) to
> specify any other information these functions need to use. That too
> follows the R way. But some people consider that bad
> programming practice.
> }
Instead of putting the extra inputs in the global environment
you might recommend putting them into a more private
environment. E.g., something like
metrop(..., outfun=local({degree=2;function(beta)beta^degree}))
Bill Dunlap
TIBCO Software Inc - Spotfire Division
wdunlap tibco.com
>
> I hope that sums it up. Apologies for submitting a rather
> stupid question
> to the list.
> --
> Charles Geyer
> Professor, School of Statistics
> University of Minnesota
> char...@stat.umn.edu
>
> ______________________________________________
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
