heogden/glmmsr

Fitting GLMMs with various approximations methods

glmmsr's Issues

adding attribute on a symbol

From Tomas Kalibera:

I am working on various parts in the core R and I found a problem in glmmsr - it is adding attributes on symbols. The code is in modify_subexpr.R, in add_sub_status:

add_sub_status <- function(x, subvar) {
if(is.atomic(x)){
attr(x, "sub") <- FALSE
x
} else if(is.name(x)) {
if(identical(as.character(x), subvar)) {
attr(x, "sub") <- TRUE # <================== here
} else {
attr(x, "sub") <- FALSE # <================== here
}
x

Adding an attribute to a symbol is very dangerous, because it has a global effect. Unlike adding it e.g. to a vector or a language object, which is fine, because these objects are copied automatically when modified. When you add an attribute to a symbol, you modify all symbols in the R session, because symbols are passed by reference, so if for example you modified a commonly used symbol like "x", all variables in the program named "x" would be impacted. We will have to turn this into a runtime error, but before we do so I am indeed letting package maintainers know. I hope in your case the fix should be simple, I think you could wrap symbol x into a "list" (or "expression" or other object) and add the attribute to that list, inside add_sub_status, yet perhaps you would have to slightly adapt the code that traverses expressions.

ambiguous use of pow and sqrt

Fails to compile in Solaris. Due to:

BasisLevel.cpp:75:46: error: call of overloaded ‘pow(int, int)’ is ambiguous
double prob = 0.5 + pow(2, -levelMax - 1);

and similarly for other uses of pow.
Similar problems with sqrt.

See https://journal.r-project.org/archive/2011-2/RJournal_2011-2_Plummer.pdf
(section "Function overloading")

problems when compiled with clang

Sometimes when compiled with clang, causes segfault when method = "SR" is used.

For example:

library(glmmsr)
(mod_SR <- glmm(response ~ covariate + (1 | cluster) + (1 | group),
               data = three_level, family = binomial, method = "SR",
               control = list(nSL = 3)))

may cause a segfault.

This is caused by removeNode, when initializing the ClusterGraph. In underlying boost graph, trying to remove an edge which doesn't exist.

broken interaction with lme4 1.1-14

See lme4/lme4#438

Handling `family = gaussian`?

On:

devtools::session_info()
##Session info -------------------------------------------------------------------
## setting  value                       
## version  R version 3.2.4 (2016-03-10)
## system   x86_64, linux-gnu           
## ui       X11                         
## language en_US                       
## collate  en_US.UTF-8                 
## tz       <NA>                        
## date     2016-03-14                  
##
##Packages -----------------------------------------------------------------------
## package  * version date       source                         
## devtools   1.10.0  2016-01-23 CRAN (R 3.2.3)                 
## digest     0.6.9   2016-01-08 CRAN (R 3.2.3)                 
## glmmsr   * 0.1.1   2016-03-14 Github (heogden/glmmsr@bb79178)
## memoise    1.0.0   2016-01-29 CRAN (R 3.2.3)                 
## R6         2.1.2   2016-01-26 CRAN (R 3.2.3)                 
## Rcpp       0.12.3  2016-01-10 CRAN (R 3.2.3)  

with the CRAN or the most recent github version.

library(glmmsr)
data(sleepstudy, package = 'lme4')
glmm(Reaction ~ (1|Subject), data = sleepstudy, family = gaussian, method = 'Laplace')

## *** caught segfault ***
##address 0x5d1, cause 'memory not mapped'
##
##Traceback:
## 1: .Call(glmerLaplace, rho$pp$ptr(), rho$resp$ptr(), nAGQinit, control$tolPwrss,     maxit, verbose)
## 2: lme4::mkGlmerDevfun(fr = modfr$fr, X = modfr$X, reTrms = modfr$reTrms,     family = modfr$family, control = lme4_control())
## 3: find_lfun_glmm_internal(modfr, method = method, control = con)
## 4: glmm(Reaction ~ Days + (1 | Subject), data = sleepstudy, family = gaussian,     method = "Laplace")