Skip to content

Conversation

fweber144
Copy link
Collaborator

This adds support for censored observations (i.e., survival or time-to-event analysis) when using the latent projection. Originally, #2 already mentioned that support for time-to-event models would be a nice feature, and the request came up again recently in https://discourse.mc-stan.org/t/using-projpred-latent-projection-with-brms-weibull-family-models/39275. This PR only makes it possible to use the latent projection for time-to-event models. For a more general perspective, see #2.

The solution presented here is not optimal because it would probably be more desirable to allow for an extension of the formula in init_refmodel() (similarly to brms's resp_cens() term), see https://discourse.mc-stan.org/t/using-projpred-latent-projection-with-brms-weibull-family-models/39275/10. Via such an extension of the init_refmodel() formula, we could also handle observation weights in a better way.

In contrast to the less elegant solution suggested in https://discourse.mc-stan.org/t/using-projpred-latent-projection-with-brms-weibull-family-models/39275/10, the solution presented here requires users to add a right-hand side formula as an attribute called cens_var to the latent_ll_oscale function. The variable named in that formula is then retrieved (internally, whenever calling the latent_ll_oscale function) from the original dataset (possibly subsetted to the observations from a given test set), newdata, or element data from varsel()'s argument d_test, whichever is applicable in the specific situation where the latent_ll_oscale function is called. The content of the retrieved variable is then passed to argument cens of the latent_ll_oscale function. In other words, the variable mentioned in the cens_var formula needs to contain the censoring indicators (e.g., 0 = uncensored, 1 = censored) which can then be used (by the user) within the latent_ll_oscale function. On the Stan Forums, I will update the Weibull (and perhaps also the log-normal) example from https://discourse.mc-stan.org/t/using-projpred-latent-projection-with-brms-weibull-family-models/39275 to illustrate this.

The solution presented here is still less elegant than the brms::resp_cens()-like solution, but in my opinion, it is preferable over the less elegant solution I suggested in https://discourse.mc-stan.org/t/using-projpred-latent-projection-with-brms-weibull-family-models/39275/10. Via the cens_var attribute, we also catch the censored-observations case (when using the latent projection) in validate_vsel_object_stats() to throw a warning if a performance statistic other than "elpd", "mlpd", or "gmpd" is used.

This is only a draft PR. Still to do:

@avehtari: A few weeks ago, we discussed how we should make this feature available and we decided to keep this feature in a separate branch. Thinking over this again, I would say we could merge this into master as soon as the to-do's from above are completed. The reason is that I consider the implementation presented here not as "hacky" as the solution we discussed back then (which was the less elegant solution I suggested in https://discourse.mc-stan.org/t/using-projpred-latent-projection-with-brms-weibull-family-models/39275/10). But I'll leave the decision up to you and @aloctavodia what you want to do with this PR. Unfortunately, I was not able to request a review from @aloctavodia for this PR.

@fweber144 fweber144 requested a review from avehtari July 26, 2025 20:09
@fweber144
Copy link
Collaborator Author

On the Stan Forums, I will update the Weibull (and perhaps also the log-normal) example from https://discourse.mc-stan.org/t/using-projpred-latent-projection-with-brms-weibull-family-models/39275 to illustrate this.

Added now at https://discourse.mc-stan.org/t/using-projpred-latent-projection-with-brms-weibull-family-models/39275/23 (for the Weibull case).

(add argument `cens` to internal `latent_ll_oscale` functions)
@fweber144
Copy link
Collaborator Author

fweber144 commented Jul 27, 2025

I forgot to add the new argument cens to internal latent_ll_oscale functions, but this is now done in commit 6b76269. The tests are running through now (i.e., they don't result in errors).

@avehtari
Copy link
Member

Thinking over this again, I would say we could merge this into master as soon as the to-do's from above are completed. The reason is that I consider the implementation presented here not as "hacky" as the solution we discussed back then

OK for me to merge when it's ready

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.

2 participants