Support augmented-data projection in projpred #1292
Conversation
…arations for the augmented-data matrix (in particular, the coercion to an augmented-rows matrix) in a wrapper function for the user-specified (or default) `ref_predfun`, the `ref_predfun` defined here in brms for the augmented-data projection case may be simplified.
default of `FALSE`. This doesn't have any consequences since `link_categorical()` is not exported anyway. And it's also not used internally. (It simply exists to be passed to projpred.)
…flexibility in specifying the reference category).
…ly()` which was performed so that `...` may be used in generics like `varsel()`, `cv_varsel()`, and perhaps a future `project()` generic to pass arguments to `get_refmodel()` *as well as* down to the divergence minimizer.
|
Thank you! Reviewing this now. As for the |
At first, I also thought this would be |
|
The reference model could serve as a well predicting model also for new data so I see no reason not to have a |
|
Thank you for this PR! Looks good to me so merging now. |
Yes, but if it's only for prediction, then there's the |
Thanks for merging! |
…()` was applied accidentally).
…ly (`link` was set accidentally as argument to `link_categorical()` `inv_link_categorical()`).
This PR should perform the final changes which are necessary to support the augmented-data projection in projpred. Note that I partly reverted some of my changes in
get_refmodel.brmsfit()introduced earlier (by PR #1159 and PR #1223). The reason is that I found a more elegant way of handling the preparations for the augmented-data projection, namely by using a wrapper function for the user-specifiedref_predfunwithin projpred. (Btw, this wrapper also handles the subtraction of the offsets, which is why we didn't have to subtract offsets in the brms-specificref_predfunin PR #1287.) Sorry for the changes inget_refmodel.brmsfit()introduced earlier which are now partly reverted. But I think the new handling is much better, especially because it requires much less changes to brms and because it avoids exporting projpred functions which would only be needed by brms.The development version of projpred currently does not support the augmented-data projection yet. If you try to create a reference model with the
categorical()or an ordinal family such ascumulative()(in order to perform an augmented-data projection), projpred will throw an appropriate error (not only the development version, but also projpred's CRAN version). That's also why I did not create aNEWSentry here in this PR.I noticed that
get_refmodel.brmsfit()has argumentnewdata. Currently, I can't think of a situation where this would be necessary, but I left it in case there is indeed a reasonable use case. However, if there are no use cases, this argument might confuse users, so then it might be worth removing it.I noticed that you recently replaced
ilinkbyinv_link(in all of the code, it seems). Some time ago, I decided to use the suffixilinkin projpred, so with this PR, you get a new occurrence ofilinkwhich, however, should not be replaced byinv_link(otherwise, we would have to change projpred code).