glmer incompatibility

[mcgregorian1]

@teixeirak this may potentially be a problem. @ValentineHerr do you have an opinion?

I've been running analyses on my laptop. The version of the lme4 package for glmer() is 1.1-21 from March of 2019.

• There is a ... option to glmer() that allows for "other potential arguments". Originally I was using REML=FALSE when using lmer, and I kept it when switching to glmer().
• When I do this, I run the code like normal and I get the normal candidate traits (RP, PLA, TLP), with the result below. (This is the Table 4 output).

I tried running the code on my Mac this afternoon for speed, and I downloaded the most recent lme4 package, which is version 1.1-23 from April of 2020.

• Here the glmer function has done away with the ... argument, which means it throws an error if I include REML=FALSE. To let the function run as before, I simply commented it out.
• When I run this version, however, I get no candidate traits as my results from running the models have completely changed. I don't know why taking out REML=FALSE (or simply removing the functionality of the ... argument) has changed the math like it has. See the table below.
• The official news describing the new release says "lmer(), glmer(), and nlmer() no longer have a formal ... argument. This defunctifies the use of a sparseX = . argument and will reveal some user errors, where extraneous arguments were previously disregarded."

So moving forward.

• in the immediate future (now and for submission), I'll keep running things on my normal computer / find a way to backtrack the version of the lme4 on my Mac so we can have a cohesive output in line with what we've been doing.
• for the future, this is where it gets challenging. I'm assuming this code will be published along with the paper, correct? Anyone who has been keeping their packages updated, or who uses lme4 in the future, will have this updated version of glmer(), which will throw an error with the code as written. If we don't change it now, then, this code will not be executable unless we specifically have a parameter that says you must have xx version of this package. The further in time we go, however, the more of a problem this will become.

Thoughts?

[ValentineHerr]

REML argument was always ignored in glmer() before. It is only used by lmer().

I could be wrong, but the difference, I suspect, is not having REML=F or not, but might due to an update in the glmm algorithm... anything about it in the news release? glmm are still at the frontier of stats so I woudn't be surprised if things changed.

[mcgregorian1]

The news release didn't say anything further than what I put in my note above, unfortunately.

[teixeirak]

This is resolved because we switched back to lmer (see issue #105).