Repository navigation
Poisson and binomial submodels: non-integer issue and lme4 issue #682 #207
Description
While working on a Poisson example for the revised vignette(s), I realized that lme4 indeed runs through for a Poisson submodel, but the lme4 run is slow and throws a lot of warnings concerning non-integer values (the warnings being suppressed by projpred, though). The reason is probably that in the submodels, the response values resulting from the reference model's predictions are not integers (in contrast to the original response).
So my first question is: Does lme4 return valid results in this case, despite the (suppressed) warnings? And my second question is: If yes, shouldn't projpred throw a warning when creating a Poisson reference model, so the user gets notified of the increased runtime?
A similar issue might exist for GAMs and GAMMs. I haven't looked into that.
For GLMs: I don't know how the projpred-internal GLM submodel fitter handles this. Perhaps this was exactly the reason why projpred has an internal GLM submodel fitter instead of using glm() (or lm(), for the Gaussian family)? If not, then the projpred-internal GLM submodel fitter might exhibit a similar issue.
In an example run with non-suppressed warnings, I did not encounter this issue for the binomial family. In principle, the binomial family could have the same issue because the reference model's predictions are probabilities there, but I guess the issue does not occur there since the usual R convention for binomial fitters is to also accept proportions for the response.
Activity
[-]Poisson submodels: `non-integer` issue[/-][+]Poisson and multilevel binomial submodels: `non-integer` issue[/+]fweber144 commentedon May 23, 2022
lme4/lme4#682 could be related to this.
[-]Poisson and multilevel binomial submodels: `non-integer` issue[/-][+]Poisson and binomial submodels: `non-integer` issue[/+]fweber144 commentedon Sep 29, 2022
PR #353 starts to address this (the code from that PR is not finished yet, though).
fweber144 commentedon Sep 29, 2022
The Poisson experiment from PR #353 indicates that in case of the Poisson family, the validity of the results when using
lme4::glmer()as GLMM submodel fitter is probably not compromised (only the runtime). This should be investigated in more detail, though (the code from the binomial example in lme4 issue lme4/lme4#682 could be a starting point). For the binomial family, lme4 issue lme4/lme4#682 does affect the validity of the results, though (as demonstrated by the binomial experiment from PR #353).I have also come to the conclusion that GLMs are probably not concerned by this issue (I mentioned the possibility of this above): The projpred-internal GLM fitter seems to have been tested thoroughly enough so that the validity should be given. Furthermore, the runtime is not an issue in case of the projpred-internal GLM fitter and the "shrinkage" of hierarchical effects as in lme4/lme4#682 cannot occur in GLMs. However,
glm()(see currently hidden optionprojpred.glm_fitter) would still need to be checked whether it returns the same results as the projpred-internal GLM fitter (some time ago, I have conducted some local experiments for this and I can share the code upon request, but these experiments would need to be extended and included in the unit tests).fweber144 commentedon Sep 29, 2022
So, in summary, as soon as the open
TODO (glmmPQL)comments from PR #353 have been solved, this issue here should be fixed as well and can then be closed.[-]Poisson and binomial submodels: `non-integer` issue[/-][+]Poisson and binomial submodels: `non-integer` issue and lme4 issue #682[/+]avehtari commentedon Oct 24, 2026
lme4 2.1-0 (CRAN, 2026-10-23) made our CI fail on this issue. The cause is in lme4, and lme4/lme4#1012 fixes it.
What happens in lme4
For the Laplace approximation,
glmer()adds the family'saic()to its objective. For binomial data, lme4'saic()rounds non-integer counts; for Poisson data, it returns-Inffor non-integer responses. projpred's submodel fits always have such data. The traditional projection passes the reference model's fitted values as responses, and the augmented-data projection passes 0/1 responses with fractional weights. Up to lme4 2.0-6,nAGQ > 1used the deviance residuals instead. Since 2.1-0 it uses the sameaic()term (lme4 commit b86d98d4).Effect on projpred
The following holds for the default
nAGQ = 1with every lme4 version so far.projpred's own GLM fitter (
fit_glm_ridge_callback()) does not have the problem, because projpred's extended families compute the deviance from the continuous extension of the densities.The lme4 fix
I reported this in lme4/lme4#1011. Ben Bolker made lme4/lme4#1012, which uses the continuous extension of the binomial and Poisson densities in
aic(); integer data give the same results as before. I tested the PR with projpred master. The traditional and the augmented-data projections give the same fits for everynAGQ, Poisson submodels estimate theta, and the full test suite passes except one test that #577 fixes.Plan for projpred
After lme4
<version>is on CRAN:<version>) inDESCRIPTION. With older lme4 versions, binomial and Poisson GLMM projections keep the errors above.glmer()submodel with fractional responses to theglm()solution; another checks that theta of a Poisson submodel moves from its start value. projpred's other tests of these submodels run only withNOT_CRAN=true.test_augdat.Rcomparisons that Adapt the tests to lme4 2.1-0 #577 skips.Then we can close this issue.
If the lme4 release takes long, I have a fallback in projpred. It passes
glmer()a renamed copy of the binomial or Poisson family with anaic()that does not round, and lme4 then calls this R-levelaic(). With lme4 2.1-0, the fallback makes thetest_augdat.Rcomparisons agree again, and the test suite passes except the test that #577 fixes. It needs lme4 >= 2.1-0, because older versions estimate a dispersion parameter for a family with an unknown name.This comment was assisted by Claude.