Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Create an average forecaster #558

Open
williewheeler opened this issue Sep 13, 2019 · 3 comments
Open

Create an average forecaster #558

williewheeler opened this issue Sep 13, 2019 · 3 comments
Labels
enhancement New feature or request good first issue Good for newcomers

Comments

@williewheeler
Copy link
Contributor

See https://otexts.com/fpp2/simple-methods.html#simple-methods

We should add a window length to allow us to take the average of the last n observations.

@williewheeler williewheeler added enhancement New feature or request good first issue Good for newcomers labels Sep 13, 2019
@bcorbett
Copy link

bcorbett commented Sep 24, 2019

Having a window length would make this a simple moving average. Incremental calculation of an SMA requires storing the values observed during that window. Looking at the various *Params classes, it looks like the moving average forecasters try to support seeding the forecaster with an initMeanEstimate.
Is this idea of seeding a forecaster a requirement? If so, for an SMA it seems like it would need to accept an initial mean value and one full window's worth of observations (e.g. 9 observations for a 9 period SMA).
Is seeding a forecaster a hard-requirement?

@williewheeler
Copy link
Contributor Author

Hey @bcorbett. +1 that this would become a SMA on my suggested change. In fact I am thinking that a SimpleMovingAverageForecaster would be more useful than a forecaster that averages the entire history. But either way is fine by me.

Seeding the forecaster is highly desirable, though we can always treat that as a future enhancement or as a config option. The reason is that at Expedia at least we do continuous delivery, and so we want to be able to redeploy the app without losing a bunch of detectors for the duration of a window. Especially in cases where we're talking about a window that includes a full season (or multiple seasons) -- it wouldn't be feasible to have a detector have to wait two weeks say to come online. The way we've been thinking about this is to have a detector call a metric store for the seed data as part of its initialization process. We haven't done that with any of the detectors yet but that's I think where we want to go.

Anyway, if you're interested in taking this on, let us know. OK with full history average and also OK if you prefer to do SMA. If you do SMA, fine to treat init as future enhancement.

@bcorbett
Copy link

Hi there, Willie. Sorry, got very busy with other work. I finally had a chance to implement this. Let me know what you think. I was able to implement the SMA with a configurable period length and optional seeded initial data set. https://github.com/ExpediaDotCom/adaptive-alerting/pull/614/files

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request good first issue Good for newcomers
Projects
None yet
Development

No branches or pull requests

2 participants