Hello, list members,
two days ago I posted a question regarding a puzzling behaviour of the
nlme-function augPred(), which was quickly answered by Jose Pinheiro
(thank you again, Jose). Below is his answer and the work-around he
provided.
Regards -- Gerrit
-------------------------------------------------------------------------
Dr. Gerrit Eichner Mathematical Institute of the
gerrit.eichner@math.uni-giessen.de Justus-Liebig-Univ. Giessen
Tel: +49-(0)641-99-32104 Arndtstr. 2, D-35392 Giessen
Fax: +49-(0)641-99-32029 http://www.uni-giessen.de/AG_Stochastik
-------------------------------------------------------------------------
Thanks for the detailed report of the problem with augPred.lmList. It is
caused by a bug in the code, as you pointed out. The basic problem is that
there is an implicit assumption in the current calculations that go on in
augPred.lmList that the data are sorted by the levels of the grouping
variable, which, of course, need not be true, as in your example. The
fitted values that form the "original" predictions in the augPred output
are sorted by groups, but when they are put together with the other
variables in the original, unordered data, it causes the mismatch you
reported. As a temporary fix before the code gets fixed, you can sort your
data according to the groups and the function should work as expected.
That is,
> kompSort <- komp[order(komp$ID),]
> augPred(lmList(kompSort))
x ID Y .type
1 1 RA1 2.7460 original
2 2 RA1 1.4510 original
3 3 RA1 1.3620 original
4 4 RA1 3.0460 original
5 1 RA2 1.5120 original
6 2 RA2 3.4180 original
7 3 RA2 3.0980 original
8 4 RA2 3.1570 original
9 1 RA3 3.1300 original
10 2 RA3 5.2640 original
11 3 RA3 2.0780 original
12 4 RA3 6.1010 original
13 1 RA1 2.0296 predicted
14 4 RA1 2.2729 predicted
15 1 RA2 2.1040 predicted
16 4 RA2 3.4885 predicted
17 1 RA3 3.2842 predicted
18 4 RA3 5.0023 predicted
|