[Rd] predict()

[Terry Therneau]

On Fri, 2011-04-15 at 09:10 +0200, peter dalgaard wrote:
> I couldn't reproduce it from Terry's description either, but there
> _is_ an issue which parallels the ....

I'll start with an apology: as a first guess to understand the problem
with predict.coxph I tried something parallel to Ivo's example using lm,
during a 5 minute slice of time between meetings.  I got a similar error
message, posted a query based on that, and ran off.  The real root of my
error message, however, was a simple typographical mistake.  My
apologies for the premature note, whose error was gently pointed out by
all three of you.  I should have waited till I had more time.

 Now for the real problem, which is an oversight in my design.  When
updating the predict.coxph, residuals.coxph, survfit.coxph and
survexp.coxph functions to more modern processing of the newdata
argument (proper handling of factors, etc), I made a decision to have
all of them call model.frame.coxph and model.matrix.coxph.  Model.matrix
in particular has some special steps, and it would be better to have
only one point of modification.
  However, this introduces one more level of indirection
        predict >- model.frame.coxph -> model.frame
and the parent.frame() reference in model.frame.coxph now points to
predict when we actually want it to point to the parent of predict.  In
predict.lm the parent.frame() argument lives in the predict.lm code.

 I see three paths to correction:
1. Make model.frame.coxph smarter.  Peter's example seems to show that
this is hard.

2. Change the line in predict.coxph (and the others)
        mf <- model.frame(object)
to some form of eval() that causes the parent.frame() operation to reach
back properly.  I'm not yet sure what variant of eval or do.call or ...
this is; the effect I'm looking for is similar to what NextMethod()
does.

3. Change my call to
        mf <- model.frame(object$terms, ...  mimic the call in lm
This may be the simplest, since model.frame.coxph does not do anything
special.

Last, I need to check whether any of the above issues affect
model.matrix calls.

Any comments on which is the better path would be welcomed.

Terry T.