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

[Adam D. I. Kramer]

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?

 	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.

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