The current version of the DESCRIPTION file for Zelig has 12 packages
listed under Depends. Writing R Extensions explains why this is a bad idea.
http://cran.r-project.org/doc/manuals/r-release/R-exts.html#Package-Depende…
Key passage:
"Field ‘Depends’ should nowadays be used rarely, only for packages which
are intended to be put on the search path to make their facilities
available to the end user (and not to the package itself): for example it
makes sense that a user of package *latticeExtra*
<http://CRAN.R-project.org/package=latticeExtra> would want the functions
of package *lattice* <http://CRAN.R-project.org/package=lattice> made
available.
Almost always packages mentioned in ‘Depends’ should also be imported from
in the NAMESPACE file: this ensures that any needed parts of those packages
are available when some other package imports the current package."
This is especially true for Zelig because of naming conflicts between some
of the packages in Depends. For me (and others?) the key issue involves
dplyr and MASS. Both have a function called "select." That function is
critically important to any user of dplyr. (I don't think it matters much
to users of MASS.) But because MASS is listed before dplyr in Depends in
Zelig, there is no way (if you have Zelig loaded) to have "select" refer to
the function in dplyr.
Also, including both plyr and dplyr in Depends seems very sloppy.
The solution (and current best practice in R) is to not use Depends so
much, if at all, and to only import functions from a package like MASS that
you actually need.
Thanks.
I *believe* that there is a bug in Zelig's scoping. This exists on the cran
version (from where it bit me) but also in the development version.
> packageVersion("Zelig")
[1] "5.0.2"
>
Interactively, the Zelig demo works fine:
> data(cars)
> x <- cars
> zelig(dist ~ speed, data = x, model = "ls")
How to cite this model in Zelig:
Kosuke Imai, Gary King, and Olivia Lau. 2007.
...
>
Note that assigning cars to x and then passing x as the argument to data is
needed to demonstrate the bug. The problem comes when we wrap this code
within a function.
> rm(list = ls())
> test_function <- function(){data(cars); x <- cars; zelig(dist ~ speed,
data = x, model = "ls")}
> test_function()
Error in callSuper(formula = formula, data = data, ..., weights = NULL, :
object 'x' not found
How to cite this model in Zelig:
Kosuke Imai, Gary King, and Olivia Lau. 2007.
...
>
It is the Error above that is the problem. (Strangely, the code still seems
to work in the development version after issuing that Error message. In the
CRAN version, it does not.)
Note that you need to keep your workplace clean to see this clearly. See
the rm(list = ls()) above. If you don't issue this command (after doing the
interactive code), you don't get any error:
> rm(list = ls())
> data(cars)
> x <- cars
> zelig(dist ~ speed, data = x, model = "ls")
How to cite this model in Zelig:
Kosuke Imai, Gary King, and Olivia Lau. 2007.
...
> test_function <- function(){data(cars); x <- cars; zelig(dist ~ speed,
data = x, model = "ls")}
> test_function()
How to cite this model in Zelig:
Kosuke Imai, Gary King, and Olivia Lau. 2007.
...
>
No Error because Zelig finds x in the global environment. Of course, it
should be using the local x.
My colleague thinks that, in the CRAN version, this snippet of code is
wrong:
divided.data <- eval(call("multi.dataset", substitute(data)))
But I am not enough of an R guru to determine the cause of the bug.
Thanks,
Dave Kane
