[R] lme4_0.995-2/Matrix_0.995-4 upgrade introduces error messages (change management)

[White, Charles E WRAIR-Wash DC]

I'll address two issues. The first is today's error message and the other is change management for contributed packages on CRAN.

TODAY'S ERROR MESSAGE

I switched from the 0.995-1 versions of lme4 and Matrix to those referenced in the subject line this afternoon. Prior to using these packages on anything else, I applied them to code that 'worked' (provided numerical results with no error messages) under the previous set of packages. Since I can't provide the data, I realize this post may be of limited usefulness. Rightly or wrongly, I've regressed my R installation back to the 0.995-1 versions of lme4/Matrix... so I don't think that I continue to have a problem. 

R version 2.2.1, 2005-12-20, i386-pc-mingw32 

attached base packages:
[1] "methods"   "stats"     "graphics"  "grDevices" "utils"     "datasets" 
[7] "base"     

other attached packages:
     lme4   lattice    Matrix 
"0.995-2" "0.12-11" "0.995-4"

> options(show.signif.stars=FALSE)
> m1a<-lmer(cbind(prevented,control.count)~repellant+hour+(1|volunteer)+(1|date),
+ family=binomial(link='probit'), method='Laplace')
Error in dev.resids(y, mu, weights) : argument wt must be a numeric vector of length 1 or length 219
> # probit doesn't converge
> m1b<-lmer(cbind(prevented,control.count)~repellant+hour+(1|volunteer)+(1|date),
+ family=binomial, method='Laplace')
Error in dev.resids(y, mu, weights) : argument wt must be a numeric vector of length 1 or length 219
> # logit is overdispersed
> m1<-lmer(cbind(prevented,control.count)~repellant+hour+(1|volunteer)+(1|date),
+ family=quasibinomial, method='Laplace')
Error in glm.fit(X, Y, weights = weights, offset = offset, family = family,  : 
	NAs in V(mu)
> m2<-lmer(cbind(prevented,control.count)~hour+(1|volunteer)+(1|date),
+ family=quasibinomial, method='Laplace')
Error in glm.fit(X, Y, weights = weights, offset = offset, family = family,  : 
	NAs in V(mu)

CHANGE MANAGEMENT

Does CRAN keep old versions of contributed packages someplace? If not, the strategy I've implemented today is to maintain my own repository of contributed packages that I use. Stuff happens and change management is good.

Chuck

Charles E. White, Senior Biostatistician, MS
Walter Reed Army Institute of Research
503 Robert Grant Ave., Room 1w102
Silver Spring, MD 20910-1557
301 319-9781
Personal/Professional Site: 
http://users.starpower.net/cwhite571/professional/