[R] fitted values in LMER for the fixed-effects only

Douglas Bates bates at stat.wisc.edu
Tue Oct 2 18:03:54 CEST 2007


On 9/29/07, Dieter Menne <dieter.menne at menne-biomed.de> wrote:
> On 9/28/07, Anouk Simard <Anouk.Simard <at> bio.ulaval.ca> wrote:
>
> > > I would like to extract the fitted values from a model using LMER but
> > > only for the fix portion of the model and not for the fix and random
> > > portion (e.g it is the procedure outpm or outp in SAS).
> ..
> Quoting Douglas Bates <bates <at> stat.wisc.edu>
>
> > > The calculation of the level = 0 fitted values in the new
> > > representation of the fitted model is quite easy. It is
> > >
> > > fm1 at X %*% fixef(fm1)"
> > >
>
> Douglas Bates replied
>
> > Yes.
>
> Mmm.. If I consider a few hundreds of messages in this list on the subject,
> it's considered dirty to use the fm1 at X or fm1$X construct. So should we
> expect that this is final (no longer fitted(), augPred etc), or is it work
> in prooogresssssssss?

This is to indicate that I am rather slow in getting the lme4 package
finished?  :-)

I agree that I am and no one is more impatient with the progress than I.

You are correct that it is considered bad form to reach into a fitted
model structure and pull out individual components or slots.  My brief
answer agreeing that this was still the best way of obtaining these
particular values should have emphasized the "still".  I haven't
thought of a good way of specifying this particular form in, say, the
"fitted" method.  There is a clean way of specifying the levels of
random effects incorporated into the fitted values for models with
nested random effects only.  However, for crossed or partially crossed
random effects this is less clearly defined.

Perhaps a better alternative would be to define a method for the
"model.matrix" generic for lmer models.  Then the calculation could be
written as

model.matrix(fm1, type = "fixed") %*% fixef(fm1)

using only extractor functions.

It may be surprising that sometimes the most difficult part of the
design of the code in a package is deciding on the names and arguments
of functions or methods.  In my experience rushing such decisions
often leads to a lot of maintenance headaches.



More information about the R-help mailing list