[R-sig-ME] Start values for glmer: Bug?
Adam D. I. Kramer
adik at ilovebacon.org
Tue Apr 27 02:32:11 CEST 2010
On Mon, 26 Apr 2010, Ben Bolker wrote:
> I don't think we really need your data, because it's easy to come up with
> a reproducible example:
>
> library(lme4)
> gm1 <- glmer(cbind(incidence, size - incidence) ~ period + (1 | herd),
> family = binomial, data = cbpp, verbose=TRUE)
>
> gm2 <- update(gm1,start=list(ST=gm1 at ST,fixef=fixef(gm1)),verbose=TRUE)
>
> ## I think what would be intended for setting only the
> ## ST parameters would be:
>
> gm3 <- update(gm1,start=list(herd=gm1 at ST),verbose=TRUE)
...gm3 appears to work, while gm2 throws the error.
This also works:
gm2 <- update(gm1,start=list(ST=gm1 at ST),verbose=TRUE)
...which suggests to me that the error is in the fixef specification, not
the ranef specification.
> ## but doesn't work?
>
> I haven't quite worked my way through the glmer_finalize logic of
> "STpars" vs "ST" list element.
>
>> But yes, the FL object is not exactly what this test thinks it is.
>> The proposed solution also doesn't seem to work: FL$fl is a list of grouping
>> factors (just one, in my case: studyID). What is the goal of this check? It
>> seems to me that we are trying to check that the items in "start" are either
>> of form 1 or form 2, but FL does not seem to me to be the key.
>
> The help says:
>
> If the list is of the same form as the ÿÿSTÿÿ slot, it
> is becomes the starting values of the ÿÿSTÿÿ slot.
>
> FL$fl seems to contain a list of random effects:
>
> Browse[2]> names(FL)
> [1] "trms" "fl" "dims"
> Browse[2]> names(FL$fl)
> [1] "herd"
>
> so checking that 'start' was a list whose names matched those of FL$fl
> would seem to be sensible.
And indeed it is--the problem is present only when one also provides fixed
effects starting values.
--Adam
>
>>
>> --Adam
>>
>> On Mon, 26 Apr 2010, Ben Bolker wrote:
>>
>>> Adam D. I. Kramer wrote:
>>>> Hello,
>>>>
>>>> I'm fitting a model something like this:
>>>>
>>>> s1d2.s <- glmer(chosen ~ rating + option + option2 + rating:option +
>>>> rating:option2 + (distNum|studyID), data=cc2, family=binomial)
>>>>
>>>> ...pretty straightforward. Of course, it doesn't converge...boo. So I turn
>>>> on verbose, and see that it's starting with some really improbable values.
>>>> So I plug in some start values from other similar matrices that fit and some
>>>> good guesses, and it chugs along and finishes, but gives me a warning I do
>>>> not understand.
>>>>
>>>> These are my start values:
>>>>
>>>>> arg
>>>> [[1]]
>>>> (Intercept) distNum
>>>> (Intercept) 1.9 0.0
>>>> distNum -0.1 0.5
>>>>
>>>>> fe
>>>> (Intercept) rating option option2 rating:option
>>>> -7.5000 1.1000 -0.3000 0.0090 0.0500
>>>> rating:option2 distNum condition1 condition2
>>>> -0.0025 0.2000 0.1000 0.1000
>>>>
>>>> ...this is my call:
>>>> s1d2.s <- glmer(chosen ~ rating + option + option2 + rating:option +
>>>> rating:option2 + (distNum|studyID), data=cc2, family=binomial, verbose=TRUE,
>>>> start=list(ST=arg,fixef=fe[1:6]))
>>>>
>>>> ...and this is the eventual completion, with the warning message I do not
>>>> understand:
>>>>
>>>> 65: 1633.7847: 2.71240 0.719770 -0.228343 -8.32184 1.56395 -0.0683526
>>>> 0.00144433 0.0226594 -0.000315729
>>>> Warning message:
>>>> In sort(names(start)) == sort(names(FL)) :
>>>> longer object length is not a multiple of shorter object length
>>>>
>>>> ...the first-round verbose output does indeed use my provided start values,
>>>> in the right order. The summary table, eventually, also uses names(fe)
>>>> instead of the actual variable names passed to glmer...which I would argue
>>>> is inappropriate behavior. But it's the problem with the length of the names
>>>> of `start` that has me confused.
>>>>
>>>> The help page says that I should be passing a list with items ST and fixef,
>>>> and I'm doing that, and it's working...
>>>>
>>>> Advice?
>>> Provide a reproducible example?
>>> (Not really meant to be snarky. lme4 is still fairly bleeding-edge,
>>> and it's quite possible that you have exposed a bug of some sort, but
>>> without digging into it it's hard to tell.)
>>>
>>> or
>>>
>>> debug(lme4:::glmer_finalize)
>>>
>>> and see what's going on (the test causing the warning is in the first
>>> line of this function).
>>>
>>> In fact, digging around further suggests that this is indeed a bug I'm
>>> not sure I've correctly reconstructed the logic of the test, which is
>>> currently
>>>
>>> if (is.list(start) && all(sort(names(start)) == sort(names(FL))))
>>> start <- list(ST = start)
>>>
>>> FL comes from a call to lmerFactorList, which returns a list with
>>> elements "trms" (terms), "fl" (factor list), and "dims" (dimensions &
>>> auxiliary information). Based on the logic of the help page, it seems
>>> that perhaps the test should be
>>>
>>> if (is.list(start) && length(start)==length(FL$fl) &&
>>> all(sort(names(start)) == sort(names(FL$fl))))
>>> start <- list(ST = start)
>>>
>>> ?
>>>
>>> cheers
>>> Ben Bolker
>>>
>>>
>
>
> --
> Ben Bolker
> Associate professor, Biology Dep't, Univ. of Florida
> bolker at ufl.edu / people.biology.ufl.edu/bolker
> GPG key: people.biology.ufl.edu/bolker/benbolker-publickey.asc
>
More information about the R-sig-mixed-models
mailing list