Add surv.finegray _coxph

[agalecki]

Thank you for contributing a learner to the mlr3 ecosystem.
Please make sure that:

• The added learner(s) are sufficiently tested
• All the CI tests are passing (including the CodeFactor)
  Fixed all CodeFactor issues. However, the "Checks" tab shows "Workflow runs completed with no jobs" for commits 65b6513. It seems other CI tests (e.g., R-CMD-check) aren’t running, possibly because this PR is from a fork (agalecki-forks). Can someone confirm or trigger the full CI suite? Thanks!
• You ran devtools::document()
• You updated the NEWS.md field to include the addition of the learner
• You did not modify anything not related to the new learner
• You are listed as a contributor in the DESCRIPTION of the R package

[bblodfon]

In the new mlr3proba update, you won't be ableto create a TaskSurv like this (with 3 event types). TaskCompRisks will be responsible for that.

[agalecki]

Thank you @bblodfon for your responses.

I noticed that in your version of mlr3proba the TaskSurv does not support type="counting". Is there another task generator that takes this responsibility?
I am also wondering whether a name similar to TaskMultStates for this type of task generator would be more "inclusive" and consistent with a convention used in Surv definition instead of TaskCompRisks.
Please consider adding an argument cmp_event_labels that allows the user to pass this information.
Thank you again

[bblodfon]

Hi,

I noticed that in your version of mlr3proba the TaskSurv does not support type="counting". Is there another task generator that takes this responsibility?

It's a new Task Class => TaskCompRisks, please see PR here, and I guess more helpful would be to see the tests.

I am also wondering whether a name similar to TaskMultStates for this type of task generator would be more "inclusive" and consistent with a convention used in Surv definition instead of TaskCompRisks

We noticed that as well, but there is a lot of stuff that is different (though conceptually competing risks is a subcase of multi state modeling), especially the prediction types (state probabilities can go up and down across time, CIF is always increasing), so we decided to split for now.

Please consider adding an argument cmp_event_labels that allows the user to pass this information.

I have, it just was so much easier to have the event types with intergers 0,1,2,3,... due to other subsetting/filtering issues with survival::Surv() that is used inside the competing risks task. I could store the event column character mapping stored somewhere I guess, but it doesn't change anything in the modeling stuff we do...

[bblodfon]

Changing the learner here to a lrn("cmprsk.finegray") that outputs a CIF as mentioned in #416 would be for the best! I included the Aalen-Johansen estimator in the mlr3proba PR so that would be a good template to follow.

[agalecki]

RE: "I noticed that in your version of mlr3proba the TaskSurv does not support type="counting". Is there another task generator that takes this responsibility?'

This issue pertains to discussion. More specifically the code

library(mlr3)
library(mlr3proba)
mytask = as_task_surv(survival::heart, time = "start", time2 = "stop", 
         event = "event", type="counting")

worked on Oct 2nd, 2024, but now the new version of mlr3proba does not support type="counting" option and throws an error:

Error in .__TaskSurv__initialize(self = self, private = private, super = super, :
Assertion on 'type' failed: Must be element of set {'right','left','interval'}, but is 'counting'.

Would you consider reinstating type="counting" option?

[bblodfon]

Yes, sorry for now answering directly - simply put, removing the type = "counting" is a design choice.

We are trying to see how we can address different censoring types and data formats (time-dependent covariates, start/stop data, etc.) and task types (multi-state vs single-event for example). The type argument above was about defining the type of censoring, but "counting" refers to the general [start, stop) data format (terminology was from Surv(...) which kinda mixes all these things). i.e. usually you also need an id column as one observation can have multiple rows in such a long format dataset. Not easy to see how we can reconcile this but definitely not impossible, we just need to make some design choices in mlr3/mlr3proba at some point.