[Rd] question about ... passed to two different functions

Charles Geyer charlie at stat.umn.edu
Mon Sep 7 22:39:07 CEST 2009


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.
}

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
charlie at stat.umn.edu



More information about the R-devel mailing list