You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
There are cases where we phase the data, and others where we use temporal data. So long as we bake the period into our predictor objects, this won't be necessary. Also, removing the distinction between phased/unphased data would make the code a lot easier to work with, and the API a lot more useful.
Doing this is a non-trivial task, due to the number of places which depend on the data being phased/unphased. While I would like to see this done in the release which we publish, for the sake of time I think it needs to be a future release.
The text was updated successfully, but these errors were encountered:
I'm going to start compiling a list of places I notice a reliance on phased data. If we start writing them down as we see them, it will be a lot easier when one of us finally goes through and fixes them all, and then there will be a checklist to make sure they're all fixed. (feel free to edit this post)
There are cases where we phase the data, and others where we use temporal data. So long as we bake the period into our
predictor
objects, this won't be necessary. Also, removing the distinction between phased/unphased data would make the code a lot easier to work with, and the API a lot more useful.Doing this is a non-trivial task, due to the number of places which depend on the data being phased/unphased. While I would like to see this done in the release which we publish, for the sake of time I think it needs to be a future release.
The text was updated successfully, but these errors were encountered: