Open nikosbosse opened 1 month ago
you only really need the function if you want to create your own forecast class.
If people want to do this in their own packages they will need this to be exported. I think this could be suited to as_forecast
(i.e we enforce all objects to have both a specific and a generic forecast class?) but I don't think we need to do that now.
Anything people need to write their own class we should explore I think. I think we probably should have a toy vignette in the near future demonstrating how to reimplement say point scoring and that will guide what should be exported or not (i.e anything it uses needs to be exported).
get_duplicate_forecasts(
The workflow here could be that users call as_forecast
again with a new forecast unit and then pass that to get_duplicate_forecasts
?
I'm proposing the following:
For now we make all these functions internal:
-as_forecast_generic()
new_forecast()
as_scores()
apply_metrics()
All these functions are only necessary if you want to build your own new forecast type. Currently that's so convoluted that nobody will do it. In version 2.1 we focus on making that process easier and export those functions.
We could potentially also make
assert_forecast()
validate_forecast()
internal. Those functions are less important now that @Bisaloo implemented automatic warnings when your forecast object becomes invalid. I'm not at all clear why we would make functions internal that we now in one minor release time we will need to make external?
More time for thinking vs. committing to maintaining stuff in the future mostly.
Functions we maybe shouldn't export anymore
EDIT: see #905
set_forecast_unit()
Reason for making it internal: It kind of duplicates theforecast_unit
argument inas_forecast_<type>()
.Argument for keeping it exported: It is useful in conjunction with the function
get_duplicate_forecasts()
. This function doesn't have aforecast_unit
argument and therefore it's helpful to have a function that can set your forecast unit (i.e. remove columns except for the ones you want).On the other hand, removing columns is somewhat trivial and also we could just add a
forecast_unit
arg toget_duplicate_forecasts()
.as_forecast_generic()
Reason for making it internal: same argument as with the functions below: you only really need the function if you want to create your own forecast class.Functions we maybe should export
The following is a list of functions that people might appreciate who want to create their own forecast class. They are used by us internally. Not sure how/whether others are supposed to use them.
new_forecast()
as_scores()
apply_metrics()
Maybe it makes sense to keep them internal for now until we actually see clear need for them?