sahirbhatnagar/casebase

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 within estimate_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 different absoluteRisk methods.

  • Then, we can get rid of all S3 methods for absoluteRisk since the code should now be agnostic to the fitting method (estimate_hazard would still be an S3 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.