On the other hand, SAS gets the same answer all three ways. And the answer SAS gets is closest to the one that R gets when using the daily cutting.
Obs _TIES_ _TYPE_ _STATUS_ _NAME_ trt prior karno _LNLIKE_ 1 EFRON PARMS 0 Converged time 0.1801972156 -0.005550913 -0.033771016 -483.9277463 2 EFRON PARMS 0 Converged time 0.1801972156 -0.005550913 -0.033771016 -483.9277463 3 EFRON PARMS 0 Converged time 0.1801972156 -0.005550913 -0.033771016 -483.9277463 proc phreg data=veteran1 outest = vet1; model time * status(0) = trt prior karno / ties = efron; proc phreg data=veteran2 outest = vet2; model time * status(0) = trt prior karno / ties = efron entry=tstart; proc phreg data=veteran3 outest = vet3; model time * status(0) = trt prior karno / ties = efron entry=tstart; data vets; set vet1 vet2 vet3; proc print data=vets width=FULL; run; -----Original Message----- From: Andrews, Chris Sent: Friday, August 23, 2019 9:18 AM To: 'Göran Broström'; r-help@r-project.org; tamas.fere...@medstat.hu Subject: RE: [R] results of a survival analysis change when converting the data to counting process format # For what it is worth, even the second fit (cuts at observation times) does not give identical coefficient estimates as using the original data structure. answer <- coef( coxph(Surv(time, status) ~ trt + prior + karno, data = veteran) ) veteran2 <- survSplit( Surv(time, status) ~ trt + prior + karno, data = veteran, cut = unique( veteran$time ) ) answer2 <- coef( coxph(Surv(tstart,time, status) ~ trt + prior + karno, data = veteran2 ) ) answer2 - answer # trt prior karno # 2.775558e-16 -1.127570e-17 -6.938894e-18 # If you cut daily, but not all the way to 999, you get a few different fits ff <- function(m) { veteran3 <- survSplit( Surv(time, status) ~ trt + prior + karno, data = veteran, cut = seq(m)) answer3 <- coef( coxph(Surv(tstart,time, status) ~ trt + prior + karno, data = veteran3 ) ) return(answer3) } answers3 <- sapply(100:999, ff) plot(100:999, answers3[1,] - answer[1]) # But certainly all these differences are of no practical importance. -----Original Message----- From: Göran Broström [mailto:goran.brost...@umu.se] Sent: Friday, August 23, 2019 5:13 AM To: r-help@r-project.org; tamas.fere...@medstat.hu Subject: Re: [R] results of a survival analysis change when converting the data to counting process format Den 2019-08-22 kl. 21:48, skrev Göran Broström: > > > On 2019-08-18 19:10, Ferenci Tamas wrote: >> Dear All, >> >> Consider the following simple example: >> >> library( survival ) >> data( veteran ) >> >> coef( coxph(Surv(time, status) ~ trt + prior + karno, data = veteran) ) >> trt prior karno >> 0.180197194 -0.005550919 -0.033771018 >> >> Note that we have neither time-dependent covariates, nor time-varying >> coefficients, so the results should be the same if we change to >> counting process format, no matter where we cut the times. >> >> That's true if we cut at event times: >> >> veteran2 <- survSplit( Surv(time, status) ~ trt + prior + karno, >> data = veteran, cut = unique( veteran$time ) ) >> >> coef( coxph(Surv(tstart,time, status) ~ trt + prior + karno, data = >> veteran2 ) ) >> trt prior karno >> 0.180197194 -0.005550919 -0.033771018 >> >> But quite interestingly not true, if we cut at every day: >> >> veteran3 <- survSplit( Surv(time, status) ~ trt + prior + karno, >> data = veteran, cut = 1:max(veteran$time) ) >> >> coef( coxph(Surv(tstart,time, status) ~ trt + prior + karno, data = >> veteran3 ) ) >> trt prior karno >> 0.180197215 -0.005550913 -0.033771016 >> >> The difference is not large, but definitely more than just a rounding >> error, or something like that. >> >> What's going on? How can the results get wrong, especially by >> including more cutpoints? > > All results are wrong, but they are useful (paraphrasing George EP Box). That said, it is a little surprising: The generated risk sets are (should be) identical in all cases, and one would expect rounding errors to be the same. But data get stored differently, and ... who knows? I tried your examples on my computer and got exactly the same results as you. Which surprised me. G, > > Göran > >> >> Thank you in advance, >> Tamas >> >> ______________________________________________ >> R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see >> https://stat.ethz.ch/mailman/listinfo/r-help >> PLEASE do read the posting guide >> http://www.R-project.org/posting-guide.html >> and provide commented, minimal, self-contained, reproducible code. >> > > ______________________________________________ > R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see > https://stat.ethz.ch/mailman/listinfo/r-help > PLEASE do read the posting guide > http://www.R-project.org/posting-guide.html > and provide commented, minimal, self-contained, reproducible code. ********************************************************** Electronic Mail is not secure, may not be read every day, and should not be used for urgent or sensitive issues ______________________________________________ R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see https://stat.ethz.ch/mailman/listinfo/r-help PLEASE do read the posting guide http://www.R-project.org/posting-guide.html and provide commented, minimal, self-contained, reproducible code.