It often seems to be the case that R packages contain multiple functions that create an object of some class
, specified by the package, with generic or non-generic methods
that apply to all objects of that class. Although it is generally easy to find out about the functions in a package, I have not found any equally straightforward way to find a precise description of the class
itself for S3 classes. I think this is at least partly intentional. Class definitions may be regarded as the sort of internal workings that, on one hand, the user should not have to think about, and on the other, may be changeable by the package creator, who wants people not to rely on them.
However, I find that I sometimes want to create additional objects of the same class
that work with the package functions that are methods for that class
. And it is not always easy to deduce what features an object must have in order to be usable by package functions that do various things to objects of that class
, especially as instances created by different functions may or may not all have exactly the same structure.
The example with which I am currently wrestling are forecast
objects created by various functions of the forecast
package. The forecast package provides a large number of functions that take forecast objects as inputs. This blog post by Rob Hyndman describes a function to do cross validation and requires an object of class forecast
as an argument The tsCV
function documentation says it takes a "forecastFunction" as an argument, which must return an object of class forecast
and have a univariate time series as its first object (of forecasts, one assumes) and have an argument h
giving the horizon. Well, that sounds easy enough. But then in Hyndman’s associated textbook, section 3.6, we are told that forecast objects contain information about the forecasting method, the data, the point forecasts, prediction intervals, residuals, and fitted values. That’s a lot of things, and I am not sure if they are all mandatory or if some are optional, or required only if you intend to use certain methods. And I don’t know anything about mandatory internal structure of the class.
Finally, I particularly want to know if the new fable package, intended as a forecast package replacement, uses the same forecast class mechanism and require the same internal structure., or if not, how they are different. I have not been able to find, in fpp3 or elsewhere, anything that either describes a change or contains a comparable description of objects of class forecast
.
I’m going to be embarrassed if there is some simple function,
you_should_know_this_dummy(package = “forecast”, class = “forecast”)
,
that returns a detailed description of the class. But I have looked for such a function every way I could think of and not found it.
O.K., my bad. I was trying so hard to find a way of locating the help file for the class description (which I don't think exists) that I overlooked the existence of a pretty good description of the
class forecast
under the functionforecast()
in the manual for the packageforecast
. Here it is:This still leaves some questions unanswered, like the format for the model information argument
model
, and for thex
argument with multivariate models. But I am hoping that these are similar to those handed to or returned by, e.g.,lm()
. I think this gives me enough to get started and to hope for informative errors.I still don't know if the
fable
package also uses objects ofclass forecast
. Theforecast
package documents theforecast()
function as a generic. Thefable
package does not document the generic, though it has a very similar list of functions that look likemethods
, e.g.,forecast.whatever
. If I figure out the answer, I'll post it here.I am also looking for a number of other package that provide time series forecast of particular types. I'm hoping that they provide output similar enough that I can use the forecast/fable functions for display, cross-validation, and so forth. We'll see.