[R-sig-ME] Start values for glmer: Bug?

[Adam D. I. Kramer]

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
>