similar to: function local to a fit

-------- Original Message -------- Subject: Re: How to obtain nonparametric baseline hazard estimates in the gamma frailty model? Date: Mon, 04 Nov 2013 17:27:04 -0600 From: Terry Therneau <therneau.terry at mayo.edu> To: Y <yuhanusa at gmail.com> The cumulative hazard is just -log(sfit$surv). The hazard is essentially a density estimate, and that is much harder. You'll notice

On examining non-linearity of Cox coefficients with penalized splines - I have not been able to dig up a completely clear description of the test performed in R or S-plus. >From the Therneau and Grambsch book (2000 - page 126) I gather that the test reported for "linear" has as its null hypothesis that the spline coefficient is the same at the center of basis. Thus, in the example

I've narrowed my scope problems with predict.coxph further. Here is a condensed example: fcall3 <- as.formula("time ~ age") dfun3 <- function(dcall) { fit <- lm(dcall, data=lung, model=FALSE) model.frame(fit) } dfun3(fcall3) The final call fails: it can't find 'dcall'. The relevant code in model.frame.lm is: env <- environment(formula$terms)

Duncan, I agree completely with "don't use attach"; if I could get all the users of the survival package to agree as well the problem in question would go away :-) I'm thinking about ways to add more effective error surveillance. Your suggestion was not horribly complex and I'll look into it further. My first foray failed because what I want (I think) is the

In the long run, coming up with a way to parse specials in formulas that is both clean and robust is a good idea - annoying users are a little bit like CRAN maintainers in this respect. I think I would probably do this by testing identical(eval(extracted_head), survival::Surv) - but this has lots of potential annoyances (what if extracted_head is a symbol that can't be found in any attached

First, as others have said please obey the mailing list rules and turn of First, as others have said please obey the mailing list rules and turn off html, not everyone uses an html email client. Here is your code, formatted and with line numbers added. I also fixed one error: "y" should be "status". 1. fit0 <- coxph(Surv(futime, status) ~ x1 + x2 + x3, data = data0) 2. p

On 24/02/2020 8:55 a.m., Therneau, Terry M., Ph.D. via R-devel wrote: > I recently had a long argument wrt the survival package, namely that the following code > didn't do what they expected, and so they reported it as a bug > > ? survival::coxph( survival::Surv(time, status) ~ age + sex + survival::strata(inst), > data=lung) > > a. The Google R style guide? recommends

Duncan, That's helpful. Two follow-up questions: 1. Where would I have found this information? I had looked at eval and model.frame. 2. What stops the following code from falling down the same rabbit hole? Shouldn't it find base::cos first? library(survival) cos <- lung coxph(Surv(time, status) ~ age, data=cos) Terry T. On 11/06/2015 07:51 AM, Duncan Murdoch

First, here is your message as it appears on R-help. On 10/14/2012 05:00 AM, r-help-request@r-project.org wrote: > I?m trying to set up proportional hazard model that is stratified with > respect to covariate 1 and has an interaction between covariate 1 and > another variable, covariate 2. Both variables are categorical. In the > following, I try to illustrate the two problems that

I mean if the person filing the bug regards style as more important than the truth of how R treats formulas then they?re literally talking in another language. I strongly recommend you do nothing or at most make a note in the documentation addressing this. Your time is too valuable. On Tue, 25 Feb 2020 at 12:56 am, Therneau, Terry M., Ph.D. via R-devel < r-devel at r-project.org> wrote:

I found an issue with the data() command this evening when working on the survival package. 1. I have a lot of data sets in the package, almost all used in at least one vignette, help file, or test.? As a space saving measure, I have bundled many of them together, i.e., the file data/cancer.rda contains 19 data sets, many of them small. The resulting file (using xz compression) is quite a bit

I was looking at how the model.frame method for lm works and comparing it to my own for coxph. The big difference is that I try to retain xlevels and predvars information for a new model frame, and lm does not. I use a call to model.frame in predict.coxph, which is why I went that route, but never noted the difference till now (preparing for my course in Nashville). Could someone shed light

On 06/11/2015 8:20 AM, Therneau, Terry M., Ph.D. wrote: > Duncan, > That's helpful. Two follow-up questions: > 1. Where would I have found this information? I had looked at eval and model.frame. I think the best description is Luke's article on namespaces, "Name space management for R". Luke Tierney, R News, 3(1):2-6, June 2003. There's a link to it from the

I tried to compare if cch() and coxph() can generate same result for same case cohort data Use the standard data in cch(): nwtco Since in cch contains the cohort size=4028, while ccoh.data size =1154 after selection, but coxph does not contain info of cohort size=4028. The rough estimate between coxph() and cch() is same, but the lower and upper CI and P-value are a little different. Can we

Dear Prof. Therneau I was impressed to discover that the 'survConcordance' now handles Surv() objects in counting format (example below to clarify what I mean). This is not documented in the help page for the function. I am very curious to see how a c-index is estimated in this case, using just the linear predictors. It was my impression that with left truncation the ordering of

Dear Terry, It's not surprising that different modeling functions behave differently in this respect because there's no articulated standard. Please see my response to Martin for my take on the singular.ok argument. For a highly sophisticated user like you, singular.ok=TRUE isn't problematic -- you're not going to fail to notice an NA in the coefficient vector -- but I've

Hi, I am trying to use the rpart library with my own set of functions on a survival object. I get an immeadiate segmentation fault when i try calling rpart with my list of functions. I get the same problem with the logrank example from Therneau,s S-rpart library though their anova example works. Should I report this as a bug, as even if my functions are structured improperly, that should lead to

I've been tracking down a survival problem from R-help today. A short version of the primary issue is reconstructed by the following simple example: library(survival) attach(lung) fit <- coxph(Surv(time, status) ~ log(age)) predict(fit, newdata=data.frame(abe=45)) Note the typo in the last line of "abe" instead of "age". Instead of an error message, this returns

Since I read the list in digest form (and was out ill yesterday) I'm late to the discussion. There are 3 steps for predicting survival, using a Cox model: 1. Fit the data fit <- coxph(Surv(time, status) ~ age + ph.ecog, data=lung) The biggest question to answer here is what covariates you wish to base the prediction on. There is the usual tradeoff between too few (leave out something

Hello R helpers: *My first message didn't pass trough filter so here it's again* I would like to obtain probability of an event for one single patient as a function of time (from survfit.coxph) object, as I want to find what is the probability of an event say at 1 month and what is the probability of an event at 80 months and compare. So I tried the following but it fails miserably. I