I've been reworking the augment() methods and it's rapidly becoming clear that dealing with idiosyncratic predict() methods is going to slow down progress immensely.
In the end broom and parsnip are both going to want to wrap a bajillion predict methods, and we should report predictions in the same way for consistencies sake. I think we should move this functionality to a separate package. Potentially we could use the prediction package by Thomas Leeper, but we should decide on the behavior we want first.
If we define a new generic / series of generics, we can then test these behaviors in modeltests and allow other modelling package developers to guarantee that their predict() methods are sane and consistent.
What I want from a predict method:
- Returns a tidy tibble
- Never drops missing data (i.e. matches the behavior of
predict.lm(..., na.action = na.pass))
- Consistent naming of fitted values
- Uncertainty in predictions
I want all of these to be guaranteed, and for methods that cannot meet these guarantees, I want an informative error rather than a partially correct output.
I've been reworking the
augment()methods and it's rapidly becoming clear that dealing with idiosyncraticpredict()methods is going to slow down progress immensely.In the end
broomandparsnipare both going to want to wrap a bajillion predict methods, and we should report predictions in the same way for consistencies sake. I think we should move this functionality to a separate package. Potentially we could use thepredictionpackage by Thomas Leeper, but we should decide on the behavior we want first.If we define a new generic / series of generics, we can then test these behaviors in
modeltestsand allow other modelling package developers to guarantee that theirpredict()methods are sane and consistent.What I want from a predict method:
predict.lm(..., na.action = na.pass))I want all of these to be guaranteed, and for methods that cannot meet these guarantees, I want an informative error rather than a partially correct output.