refactoring absoluteRisk
Closed this issue · 0 comments
Because of the changes recently made to the way we do numerical integration in the package, a lot of the code for absoluteRisk
is no longer very clean. For example, the code creates lambda
functions for the hazard functions that were designed to be passed to integrate
, but it's probably not the most efficient way to do Monte Carlo (which is the last remaining use case). We should be able to leverage the newly created function estimate_hazard
for MC integration as well. So here are the next steps for refactoring absoluteRisk
:
-
Take care of
offset = 0
withinestimate_hazard
, as this is the most natural place to do it. -
Make sure the argument
ci
is passed to the appropriate predict functions (related to issues #77 and #91) -
Rewrite the MC integration code to use
estimate_hazard
. -
Remove the
lambda
functions from the differentabsoluteRisk
methods. -
Then, we can get rid of all
S3
methods forabsoluteRisk
since the code should now be agnostic to the fitting method (estimate_hazard
would still be anS3
generic).
Note that I only plan to rewrite the code for the single event setting. The competing risk setting is a bit more complex because of the double integrals and the fact that we could have many competing events and therefore many cause-specific hazards, and we need that flexibility.
This represents a lot of work, and so that's why I'm breaking it down into manageable pieces after which I can test to make sure I didn't break anything. On the other hand, since the interface is not changing, we shouldn't be breaking any code (except code that explicitly called some of the methods, e.g. absoluteRisk.glm
), and it shouldn't interfere with the writing of our manuscript.