Add a generic wrapper for forecasting classes.

[mertozer94]

Issue

This is a base class where raw stream of inputs x are transformed into a data stream x, y1,y2,...,yk where k is defined as a parameter to the number of steps to forecast and the training is done such as (x=x[t-1], y=x[t+k]) at moment t. Also training of the model is trivial to the user.

Changes proposed in this pull request:

• A new base class for forecasting.

---

Checklist

• Code complies with PEP-8 and is consistent with the framework.
• Code is properly documented.
• Tests are included for new functionality or updated accordingly.
• Travis CI build passes with no errors.
• Test Coverage is maintained (threshold is -0.2%).
• Files changed (update, add, delete) are in the PR's scope (no extra files are included).

[codecov]

Codecov Report

Merging #162 into master will decrease coverage by 0.04%.
The diff coverage is 66.66%.

@@            Coverage Diff             @@
##           master     #162      +/-   ##
==========================================
- Coverage   88.39%   88.34%   -0.05%     
==========================================
  Files         185      185              
  Lines       13566    13595      +29     
==========================================
+ Hits        11992    12011      +19     
- Misses       1574     1584      +10     

Impacted Files	Coverage Δ
src/skmultiflow/core/base.py	77.37% <62.96%> (-2.01%)	⬇️
src/skmultiflow/core/__init__.py	100.00% <100.00%> (ø)

[jacobmontiel]

Thanks for the PR @mertozer94

Pinging @jmread to get feedback on this.

Note: codcov error is due to missing tests for the new code.

[jmread]

This looks promising!
In your comment above, I think you mean (x=x[t-1], y=x[t+k])? (To take into account k). Or you do mean (x=x[t-k:t-1], y=x[t]). Or a combination of these (there is one k or two?).

[mertozer94]

Thanks for the PR @mertozer94

Pinging @jmread to get feedback on this.

Note: codcov error is due to missing tests for the new code.

Thanks for the advice I will add some test cases as soon as possible. Also next time I will try to run locally 'codecov' but are there any other things that I should better check before pushing my commits? Like code coverage etc .

[mertozer94]

This looks promising!
In your comment above, I think you mean (x=x[t-1], y=x[t+k])? (To take into account k). Or you do mean (x=x[t-k:t-1], y=x[t]). Or a combination of these (there is one k or two?).

Thank you for the response. You are right, I meant (x=x[t-1], y=x[t+k]). I will modify it right now. But I am open for discussion on this subject.

[mertozer94]

This looks promising!
In your comment above, I think you mean (x=x[t-1], y=x[t+k])? (To take into account k). Or you do mean (x=x[t-k:t-1], y=x[t]). Or a combination of these (there is one k or two?).

Thank you for the response. You are right, I meant (x=x[t-1], y=x[t+k]). I will modify it right now. But I am open for discussion on this subject.

Actually, I think I have responded a bit quickly. What I had in my mind first was the training was done via (x=x[t-1], y=x[t]), and since I was thinking that forecasting was basically k times predicting the next value we could simply call predict function repeatedly k times. I now see that this is not possible.

I realize that I had in mind (x=x[t-k:t-1], y=x[t]). As I said, I am open for discussion on this one.

[jmread]

I realize that I had in mind (x=x[t-k:t-1], y=x[t]). As I said, I am open for discussion on this one.

I think the most generic option is (x=x[t-k:t-1], y=x[t::t+l]) to allow multi-step forecasting into the future since multi-output learning is also an integral part of scikit-multiflow (of course, l=1 would be a nice default). But maybe the t:t+l part could be an extension of the wrapper.

[mertozer94]

I realize that I had in mind (x=x[t-k:t-1], y=x[t]). As I said, I am open for discussion on this one.

I think the most generic option is (x=x[t-k:t-1], y=x[t::t+l]) to allow multi-step forecasting into the future since multi-output learning is also an integral part of scikit-multiflow (of course, l=1 would be a nice default). But maybe the t:t+l part could be an extension of the wrapper.

I agree that this is more generalized. But this means that, users needs to specify k and l before the training phase. Like you said, if they are not present, we can have some default values for them.

[jmread]

I agree that this is more generalized. But this means that, users needs to specify k and l before the training phase. Like you said, if they are not present, we can have some default values for them.

Yes, I believe that k=1 and l=1 will make good defaults.

There are numerous options that could be considered to extend this even further. For example, y=x[t+l] (a single, but long-range forecast). This has some relation to delayed labels. But this kind of flexibility could be added later. Even the simplest case with k=1,l=1 will open up many possibilities for the framework leveraging existing methods.

[mertozer94]

Hey @jmread, I have included changes. Although, for the unit test, I can only imagine to test it via it's sub classes. Do you have any recommendation on that?

[jmread]

Hey @jmread, I have included changes. Although, for the unit test, I can only imagine to test it via it's sub classes. Do you have any recommendation on that?

Other than testing the handling of different values for the parameters k, l, indeed most of the testing can be done with the actual methods employed for the forecasting.

[mertozer94]

Hey @jmread, I have included changes. Although, for the unit test, I can only imagine to test it via it's sub classes. Do you have any recommendation on that?

Other than testing the handling of different values for the parameters k, l, indeed most of the testing can be done with the actual methods employed for the forecasting.

I have added unit tests without creating a subclass.

[mertozer94]

Hello @jacobmontiel @jmread It's been a long time, but do you have any idea on how we can improve the code coverage ?

Hey @jmread, I have included changes. Although, for the unit test, I can only imagine to test it via it's sub classes. Do you have any recommendation on that?

Other than testing the handling of different values for the parameters k, l, indeed most of the testing can be done with the actual methods employed for the forecasting.

I have added unit tests without creating a subclass.

[AnkurDebnath35]

@mertozer94 Can you share a sample code for the forecasting model which can handle stream data in an online fashion and is compatible with other functions of multiflow, like DriftDetectors?

[AnkurDebnath35]

@mertozer94 I am unable to checkout this commit, throws out a "fatal:reference is not a tree" error while using the correct sha. Can someone help?