Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Added cumulative hazard #7

Merged
merged 4 commits into from
Dec 18, 2017
Merged

Added cumulative hazard #7

merged 4 commits into from
Dec 18, 2017

Conversation

piever
Copy link
Contributor

@piever piever commented Dec 18, 2017

This is a refactoring to allow the computation of the Nelson-Aalen estimator with the same machinery set up for Kaplan-Meier. This takes care of point 3 in #5 .

Nelson-Aalen estimates the cumulative hazard. Cumulative hazard H is linked to survival S via the formula:

exp(-H) = S

So it can also be used to estimate the survival. It has the advantage, compared to Kaplan-Meier, that it can be used also to get baseline cumulative hazard of a fitted Cox Model (whereas getting the survival function from a Cox model with Kaplan-Meier is somewhat convoluted in case of simultaneous events)

@ararslan
Copy link
Member

Nice refactoring, I like it! Though do you think it will be extensible to cumulative incidence, which also needs to track the number of competing events?

@piever
Copy link
Contributor Author

piever commented Dec 18, 2017

Not sure, maybe the best is to add some compute_competing variable defaulting to false and add compute_competing && before the lines that are exclusive to cumulative incidence/estimators that need the number of competing events. Compiler in 0.7 should be smart enough that there is no penalty at all for this right?

@ararslan
Copy link
Member

Compiler in 0.7 should be smart enough that there is no penalty at all for this right?

Perhaps, I'm not entirely sure.

One notable difference is that you need the vector of competing events as another argument to the estimating function, so branching on compute_competing won't get us all the way there.

@piever
Copy link
Contributor Author

piever commented Dec 18, 2017

Fair enough: It may actually be better to simply duplicate the code...

@ararslan
Copy link
Member

ararslan commented Dec 18, 2017

Keyword arguments in 0.7 are fast, since they're based on NamedTuples, so I wonder if we could get away with doing something clever hacky, e.g.

function f(time, status; kwargs...)
    if haskey(kwargs, :compete)
        # do stuff
    end
    # more stuff
end

Not sure though.

@ararslan
Copy link
Member

Regardless, this refactoring and the addition look good to me.

@ararslan ararslan merged commit efecd69 into JuliaStats:master Dec 18, 2017
@piever piever deleted the chaz branch December 19, 2017 01:39
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants