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

[Ben Bolker]

Adam D. I. Kramer wrote:
> Hi Ben,
> 
>  	I'd rather not publish my dissertation data online before it's
> analyzed, but I will email you a copy of the data.frame personally if you
> like. Others interested in this debugging process should email me
> personally; should I use this address?

  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)

## 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.

> 
> --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