[Rd] Anomaly in [.terms

[William Dunlap]

> -----Original Message-----
> From: r-devel-bounces at r-project.org 
> [mailto:r-devel-bounces at r-project.org] On Behalf Of Terry Therneau
> Sent: Monday, February 21, 2011 11:32 AM
> To: r-devel at r-project.org
> Subject: [Rd] Anomaly in [.terms
> 
> 
>  This arose when working on an addition to coxph, which has 
> the features
> that the X matrix never has an intercept column, and we 
> remove strata()
> terms before computing an X matrix.  The surprise: when a terms object
> is subset the intercept attribute is turned back on.

I've wondered about how to deal with terms objects
whose formula and attributes disagreed with each
other.  In your case the intercept attribute was 0
but there was no -1 in the formula and you (and others)
complained that [.terms respected the formula and not
the attributes.  In another case you can set the response
attribute to 0 but leave the response term in the formula.
Then [.terms alters the formula to drop the response term.
  > t <- terms(y ~ x1 + x2)
  > attr(t, "response")
  [1] 1
  > attr(t, "response") <- 0
  > t[1]
  ~x1
  attr(,"variables")
  list(x1)
  attr(,"factors")
     x1
  x1  1
  attr(,"term.labels")
  [1] "x1"
  attr(,"order")
  [1] 1
  attr(,"intercept")
  [1] 1
  attr(,"response")
  [1] 0
  attr(,".Environment")
  <environment: R_GlobalEnv>
  > version$version.string
  [1] "R version 2.12.1 (2010-12-16)"
Is altering the formula to match the attributes desirable?

I suspect you would be displeased if [.terms added
a -1 to the formula if the intercept term were 0.

If you have a terms object without a response in
the formula and you set the response attribute to
1 then [.terms just gets mixed up.  Altering most
other attributes of a terms object risks confusing
lots of functions.

Should R have a function to set the intercept term
to a legal value so we could say that directly altering
the attributes of a terms object should never be done?

Bill Dunlap
Spotfire, TIBCO Software
wdunlap tibco.com 

>   My lines 2 and 3 below were being executed just before a call to
> model.frame.  The simple solution was of course to do them in the
> opposite order so I am not waiting on a "fix". 
>   Not to mention that I am not sure a fix is required, though I was
> surprised. 
>     Terry T.
> 
> 
> tmt1131% R
> 
> R version 2.12.0 (2010-10-15)
> Copyright (C) 2010 The R Foundation for Statistical Computing
> ISBN 3-900051-07-0
> Platform: x86_64-unknown-linux-gnu (64-bit)
> 
> > test <- terms(Surv(time, status) ~ age + strata(ph.ecog),
> +    specials='strata')
> 
> > attr(test, 'intercept') <- 0  #turn off intercept
> > test <- test[-2]   #remove strata
> 
> > test
> Surv(time, status) ~ age
> attr(,"variables")
> list(Surv(time, status), age)
> attr(,"factors")
>                    age
> Surv(time, status)   0
> age                  1
> attr(,"term.labels")
> [1] "age"
> attr(,"specials")
> attr(,"specials")$strata
> NULL
> 
> attr(,"order")
> [1] 1
> attr(,"intercept")
> [1] 1
> attr(,"response")
> [1] 1
> 
> ______________________________________________
> R-devel at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>