moving_avg forecasts should not include current point

[polyfractal]

• Forecasts should include all points up to, but not including, the current point.
• Fixes some tests
• Removes the "Gap" tests, which have proven to be super fragile due to accumulated edge cases, and aren't even very useful anymore because the mockHisto stuff generates randomly sized gaps.
• Removes the concrete implementation of predict(), which makes things simpler / more intuitive

[uboness]

values.isEmpty()

[colings86]

The two checks (values.size == 0 and numPredictions < 1) seem to be done in all the models, maybe we should move them to the super class and have the sub-classes implement doPredict() which is called from the predict() method in the super class?

[colings86]

in fact, to make all the models work in the same way, we could make MovAvgModel declare the following abstract method:

 public abstract <T extends Number> double[] next(Collection<T> values, int numForecasts);

Then the predict and next methods can just be declared in MovAvgModel and be the following:

    public final <T extends Number> double[] predict(Collection<T> values, int numPredictions) {
        return next(values, numPredictions);
    }

    public final <T extends Number> double next(Collection<T> values) {
        return next(values, 1)[0];
    }

[polyfractal]

I went with the first suggestion, rolling the checks/assertion into predict() which then calls down to doPredict().

I couldn't do the second suggestion, because not all the models follow that pattern. Simple / Linear / Ewma only know how to forecast one value at a time. E.g. they always return a single value, not an array. Which also means their prediction code needs to fill the array of predictions with that last value, whereas HL/HW generate new predictions at each point.

If we want less code c/p, going back to the old solution is probably best (concrete predict() for simple/linear/ewma and have HL/HW override it).

[polyfractal]

@uboness @colings86 Sorry for delay, fixes applied

As an aside, the work I've been doing on the optimizer is going to need a fair amount of change to the next() and predict() interfaces...the current setup just isn't going to be ergonomic enough to deal with an optimizer changing model parameters constantly.

[colings86]

LGTM