Add a basic Holt-Winters algorithm to the query engine

[nathanielc]

This PR adds a basic implementation of the Holt-Winters forecasting method. Specifically the Damped Additive Trend and Multiplicative Seasonal version.

Holt-Winters expects the data be on a regular time intervals as such an aggregate function and group by time are always required.

The basic usage is as follows assuming you are receiving values every 1m:

SELECT holt_winters(first(value), 10, 4) FROM mymeasurement WHERE time > now() - 1h GROUP BY time(1m)

The holt_winters method will return 10 forecasted points past the end of the selected data, for a total of 10m of data. The second argument is the seasonal value. In this example we are saying that the data is expected to have a repeating seasonal pattern every 4 data points (aka 4m). A value of 1 or less will disable seasonal evaluation, since a seasonal period repeating every 1 or fewer times has no meaning.

If you want the full fit data returned in addition to the forecasted data use holt_winters_with_fit

SELECT holt_winters_with_fit(first(value), 10, 4) FROM mymeasurement WHERE time > now() - 1h GROUP BY time(1m)

This will return the a total of 70 points spaced 1m apart. The first 60 points represent the fitted data from the holt_winters method and the last 10 points are the forecasted points, which are the same 10 points returned when holt_winters is called.

Holt-Winters will greatly benefit being able to phase shift group by boundaries since in many cases data points and seasonal patterns may not line up exactly with our default group by boundaries.

Questions:

• Where should the neldermead package live? Inside influxql seems odd but works for now. Nelder-Mead is a numeric optimization(aka minimization) algorithm that is used by the holt_winters method.

TODO:

• Rebased/mergable
• Tests pass
• CHANGELOG.md updated
• Implement for other types beyond float64
• Update functions_test.go to expect actual values.

[dgnorton]

Error message will be 1th arg or 2th arg. https://play.golang.org/p/GpCOR6nn_O

[e-dard]

Aside from a couple of bits to address, overall the code looks good. Not sure about where neldermead package should live to be honest.

I have a more general question about the methodology for non-seasonal forecasting. Holt Winters is not good for non-seasonal forecasting but I see it's dynamically supported in this PR when the number of seasonal periods is fewer than 2. What approach are you using when not using the seasonal component?

[nathanielc]

In answer to question 2, by removing the seasonal component of the forecasting the method reduces to a Holt like algorithm, specifically the Damped Additive Trend method in the family of exponential smoothing methods.

As for

Holt Winters is not good for non-seasonal forecasting

This is true if you try and apply the seasonal component to something non seasonal, but it works well if you turn off the seasonal component.

Specifically the included tests have two data sets, a seasonal data set and a non-seasonal dataset.

Here is a screen grab of a non-seasonal fit.

[nathanielc]

Notice how the fit in this graph is always slightly higher than the actual data?

Query: SELECT holt_winters_with_fit(first("pop"), 4,0) FROM "uspop" WHERE ... GROUP BY time(90d)

Also notice that the fit line (yellow) starts before the data line (green)? This is because the fit line has to land on 90d boundaries, and the data is slightly offset from those points. If you were to slide the yellow line right by the difference you would see a much better fit.

This is what I mean that the holt_winters method will benefit from being able to shift group by boundaries in time.

[nathanielc]

@e-dard @dgnorton Thanks for the review. How does it look now?

[e-dard]

LGTM 👍

[nathanielc]

FWIW The ability to slide group by boundaries as added in master already ;)

Here is a screenshot with a better fit using the group by offset.

Query: SELECT holt_winters_with_fit(first("pop"), 4,0) FROM "uspop" WHERE ... GROUP BY time(90d, 71d)