So in this video, we will continue looking at how to implement vector out of aggression in Python.
This lecture will continue where we left off, where we've just learned how to use Varma.
The next step will be to test of Arpit model to see how it performs.
So we'll start by creating of our object, passing in the train set as before.
Note that at this point we do not pass in ENPI.
The next step is to call the select order function to see what the different information criteria would
select.
Not that I've arbitrarily chosen Max LAG's equals 15, but you can feel free to try other values.
OK, so you can see that this returns a leg order results objet.
The next step is to print out the selected orders attribute.
OK, so this is a dictionary where the key is the information criterion and the value is the order chosen
if we use that criteria on notice that they do not all agree.
The next step is to call model that fit passing in the max lags and information criterion again.
Now, because we've had to do this, it should be clear that calling select order doesn't really have
any impact.
So that step isn't strictly necessary.
You should use that for information only, but it doesn't affect how the model is actually estimated.
OK, so notice how this train's much faster compared to Vamo.
The next step is to get the gag order chosen by the AIC.
Note that this is stored in an attribute called K.
Underscore R.
The next step is to call the forecast function, but as you recall before doing so, we need to also
pass in the prior values of the Time series.
This works differently than the other models we've seen, which only allow you to forecast after the
data you passed into the constructor.
So here we call trained on look and grab the last leg or values.
The next step is to index the result at the relevant columns.
The third step is to convert it into an umpire, Ray.
You'll notice that in the documentation that the forecast function input is specified as an umpire.
Ray, this is unlike the other functions we've seen in static models which work with data frames.
So we'll call this the prior not to be confused with other uses of the same word.
For example, in Bayesian machine learning, the next step is to call the forecast function passing
in our prior time series along with and test the number of steps to forecast.
Now, again, note that this API is not like the other models we've seen, so this does not return a
forecast result.
Objects instead of this just returns an array.
If you want to print this out to confirm that, please do.
The next step is to store our predictions in our data frame.
So for the train set, we simply call the fitted values attribute as before for the test set.
Since the prediction is an umpire, Ray, we're going to index the array at the zero with column.
This is because Aukland comes before Stockholm in our data frame.
The next step is to plot the last one hundred steps of our prediction as before.
OK, so we can see that our forecast looks pretty good.
The next step is to do the same thing, except for Stockholm instead of Auckland.
Note that this time we index the forecast in column one instead of column zero.
OK, so again, we see that our forecast looks pretty good.
The next step is to compute the square of our predictions, since this code is exactly the same as before.
I won't explain it again.
OK, so for Auckland, it looks like our forecast is not as good as Varma.
The next step is to look at the R-squared for Stogel.
And again, we see that our forecast is not as good as Varma.
OK, so the next step is to establish a baseline, which will be just pure Arima.
So we'll begin by importing the Arima class.
The next step is to build and evaluate an Arima for every column in our data set individually so you
can see that we loop through each column in our list of columns inside the loop, we create an Arima
object with pixels 10 and Q equals 10, which is the same as before.
But note that in total is a rhema.
Models have fewer parameters than Varma since they do not contain any cross terms.
The next step is to get the forecast for test time steps.
The next step is to compute the square for both train and test.
OK, so let's run this.
So we see that for both Auckland and Stockholm, our Arima baseline does better the square to smaller,
but the test, our square is larger.
This means that these models overfit less intuitively.
We might understand that this should be the case since the two cities we chose are far apart.
So it could be the case that their weather does not have any effect on each other, in which case any
correlation we find is due to noise.
Using a arima eliminates those cross terms, which removes that possibility.
As always, it's best to simply check, to see what works best and to choose the model that outperforms
the others.
In this case, it appears that our baseline is the better choice.