Re: new behavior in model.response

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: new behavior in model.response

R devel mailing list
I now understand the issue, which leads to a different and deeper issue which is "how to
assign a proper length to Surv objects".

 > Surv(c(1,2,3), c(1,0,1))
[1] 1  2+ 3

The above prints as 3 elements and is conceptually 3 elements. But if I give it length
method to return a 3 then I need a names method, and names<-  pays no attention to my
defined length. How do we conceive of and manage a vector whose elements happen to require
more than one storage slot for their representation?  An obvious example is the complex
type, but it seems that had to be baked right down into the core.



        [[alternative HTML version deleted]]

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: new behavior in model.response

Achim Zeileis-4
On Thu, 28 Jun 2018, Therneau, Terry M., Ph.D. via R-devel wrote:

> I now understand the issue, which leads to a different and deeper issue
> which is "how to assign a proper length to Surv objects".
>
> > Surv(c(1,2,3), c(1,0,1))
> [1] 1  2+ 3
>
> The above prints as 3 elements and is conceptually 3 elements. But if I
> give it length method to return a 3 then I need a names method, and
> names<-  pays no attention to my defined length. How do we conceive of
> and manage a vector whose elements happen to require more than one
> storage slot for their representation?  An obvious example is the
> complex type, but it seems that had to be baked right down into the
> core.

I think you just have to implement all methods required to make it look
like a vector even if it is internally a matrix. Thus, you need methods
for length and for names and names<-. Internally, the names can be stored
as row names.

Further useful methods for "Surv" objects might include
- as.double/as.integer (presumably just extracting the "time"),
- c
- str

Possibly also a dedicated summary.

An example for such a class is our "paircomp" in "psychotools". But I'm
sure there are other/better examples elsewhere.

Best,
Achim
______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: new behavior in model.response

Berry, Charles


> On Jun 27, 2018, at 3:58 PM, Achim Zeileis <[hidden email]> wrote:
>
> On Thu, 28 Jun 2018, Therneau, Terry M., Ph.D. via R-devel wrote:
>
>> I now understand the issue, which leads to a different and deeper issue which is "how to assign a proper length to Surv objects".
>>
>> > Surv(c(1,2,3), c(1,0,1))
>> [1] 1  2+ 3
>>
>> The above prints as 3 elements and is conceptually 3 elements. But if I give it length method to return a 3 then I need a names method, and names<-  pays no attention to my defined length. How do we conceive of and manage a vector whose elements happen to require more than one storage slot for their representation?  An obvious example is the complex type, but it seems that had to be baked right down into the core.
>
> I think you just have to implement all methods required to make it look like a vector even if it is internally a matrix. Thus, you need methods for length and for names and names<-. Internally, the names can be stored as row names.


I think a closer look at model.response() would help.

IIUC, the reasoning therein is that comparing

        length(data[[1L]]) (aka `length(v)')

to

        length(attr(data, "row.names")) (aka `nrows')

is to decide whether names are sensibly assigned to `v'. I think for Surv objects they are not.

I suppose you could define

        `names<-.Surv` <- function(...) NULL

but that seems so silly I think there must be a better way.

I am low on coffee right now, but I wonder if having a non-exported version of model.response in the survival package would solve this without breaking anything else.

Chuck

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel