Consider extending glms, esp. glmboost to other compositions

[RaphaelS1]

Currently glmnet, cv.glmnet and glmboost all assume a proportional hazards form for the distr return type. This is natural for glmnet and cv.glmnet who are fit with a Cox link however glmboost can be fit using multiple families. Whilst I don't think it's incorrect for the only composition to be Cox PH, I think adding other options in the future would be a good addition.

[fkiraly]

I think the best way to extend would be an abstract compositor/reductor: take one method for the conditional risk, and then have one compositor/reductor per different strategy based on how you arrive at a conditional hazard function. Possibly sitting in one inheritance sub-tree.

At some point, I also think it would be nice that there is a "proportional hazards" compositor, that takes a risk predictor and a baseline hazard estimator. Given many of the "on-shelf" (i.e., described in literature but not properly implemented) methods are obtained in this way.

[RaphaelS1]

I think the best way to extend would be an abstract compositor/reductor: take one method for the conditional risk, and then have one compositor/reductor per different strategy based on how you arrive at a conditional hazard function. Possibly sitting in one inheritance sub-tree.

Whilst a nice idea in principle I think this is against the mlr3 design principles. This involves a multi-step process that most users will want to avoid in favour of just returning an estimated distribution. For the majority of survival learners they are based on fitting a linear predictor and then estimating the baseline hazard, which can be chosen as a hyper-parameter. Adding a abstract compositor to do this is likely a complication that will be unwanted for most

[RaphaelS1]

However you could have a transformer that changes the default compositor method to another?

[fkiraly]

I don't think there are mlr3 design conventions about task reduction and composition that go beyond the pipeline formalism? (are there?)

The problem is there are multiple possible choices by which you can convert/compose a risk prediction to a distribution prediction.

I agree that it might be nice to have one of these (the "default") just as a "reduction" step rather than a 2-argument-compositor.

On the second suggestion, having a transformer that mutates hyper-parameters of the compositor, I think that's a hack rather than a sound (or generalizable) design.
I think it's cleaner to have a default reduction and optional compositors instead, rather than one reduction/composition object with a massive hyper-parameter set - the parallel for learners would be having a single learner with a massive case-distinction-by-hyper-parameter-choice.

[RaphaelS1]

I don't think there are mlr3 design conventions about task reduction and composition that go beyond the pipeline formalism? (are there?)

No there are not

On the second suggestion, having a transformer that mutates hyper-parameters of the compositor, I think that's a hack rather than a sound (or generalizable) design.

This isn't exactly what I meant. More that these are two distinct options.

---

First assume this applies to models that predict a linear predictor only. Then

Case 1

Model includes two hyper-parameters:

1. estimator: For selecting the estimation method of the baseline hazard, with the possibility of extending this to parametric baselines
2. model_type: For selecting one of proportional hazards, accelerated failure time, or proportional odds

Then the linear predictor is returned by the prediction method and composed using the selected estimation method with the selected model type.

Case 2

A models prediction returns a linear predictor, which is then passed to an abstract compositor which would look roughly like

lp2surv(lp, method = "Breslow", model_type = "PH")

Which returns a distr6 object.

---

The problem with Case 2 is that this means a survival learner will only return a linear predictor. I think the sensible compromise is that a survival learner returns a linear predictor and a default composition method. Then the compositor can ignore the default survival distribution and only use the linear predictor for the transformation. However, the problem here is that mlr3tuning has very good support for case 1 and the user can then tune the estimation method and model type, whereas this is more complex in Case 2

[RaphaelS1]

See #30 and #31