EViews.com

Hello!

I think, there is inconsistency in the Pillips-Perron Unit Root Test when we change the first point in sample interval. I can show it using attached example.

In the workfile I calculate PP test (Level, No trend, No Intercept, Lag=1, Spectral estimation method - AR spectral, OLS) for y using sample 2005m1 2012m4. Test model is estimated from 2005m2, but in fact it use first observation (2005m1) to get results. AR OLS model use lagged d(y), so it starts from 3rd point (2005m3).

Now I change sample - set 2005m2 2012m4. First model is the same: estimated from 2005m2, but in fact it use first observation. But HAC corrected variance has changed! I estimate equation d(y) y(-1) d(y(-1)) separately, using both samples, and results are equal.

In short, in second case (sample 2005m2 2012m4) AR model discard 1st observation and can calculate only from 2005m4. I think, it is incorrect to discard this observation only in one model.

I will be REALY HAPPY if you'll look my example and give me reasonable explanation.

Thank you

The following code runs the two tests that you describe The results are identical in both EViews 7 and EViews 6.

What version of EViews are you using?

It is repeated only for AR spectral estimation method.
I use EViews 7, the last patch I've downloaded was dated October, 3rd (EViews7Patch_100312)

Sorry, I missed the long-run variance setting. I'll take a look when I get in to the office.

The differences have to do with the different samples you've provided. When you use the 2005m01 2012m04 sample instead of the 2005m02 2012m04 sample, we have an additional observation that we are allowed to use, where possible.

For the OLS regression, there are no differences as we simply drop the first observation when we take the differences. For the computation of the LRVAR using the prewhitening regressions, as you have discovered, there are differences. Basically, we first do any detrending using the sample that you provide, then run a difference regression on the results. Thus, when we do the detrending step using the smaller sample we form detrended data for one fewer observation than when doing so for the larger sample.

The reason this doesn't show up in the OLS regression is that we can use the original data to form the difference when using the smaller sample. Thus, you don't lose an extra observation when running a difference regression with the specified sample (2005m02 --) since the lag observation is available. But you can't do this when differencing the detrended data. In the LRVAR you do lose the observation since we don't have the corresponding lag value for the detrended series.

I hope that this answers your question.

I see difference for AR spectral - OLS, this option doesn't use detrending.

It goes through the detrending code which gives a set of values for your sample in all cases. So even if none is selected, the output of the procedure is to give you the sample that you specified, which is then differenced.

Is it the same detrending, that is used in Dickey-Fuller GLS? When I calculate DF GLS test using different start point - I get the same result. According you logic results should differ because detrending starts from different points.

It's a different function. That said, the reason that they differ is that the DF-GLS routine has special code to adjust the sample to account for additional lags prior to doing the GLS transform. The GLS transform is done on the lag augmented sample so that the presample values are available for the final estimation. This is why there are no differences between the two samples in this case.

The autoregressive spectral estimation doesn't do this extra adjustment, though in principle it could. I don't think there is a right answer as to whether the adjustment should be done or not.

In both the AR spectral and the DF-GLS case, the downside is that then the deterministic adjustment (either OLS or GLS) is then done on a sample that is slightly larger than the estimation sample. The upside is that we get the maximum number of presample observations as you adjust the sample for the lags. And in the case where there is no deterministic adjustment, we match what you would get if you took the lagged data directly from the workfile.

I have temporary code in which does this adjustment, but am not yet certain that I want to introduce it into the main code base (though I am leaning toward doing so). The question of how presample lags should be used is not a simple one and often depends on context. I'll note that all of these are consistent estimators of the long-run variance and or unit root test and as noted above there are upsides and downsides to making the adjustment.

I think you should now understand the issues and I'd be curious as to your (and anyone else who is playing along at home) opinion.

Thank you for the complete explanation. As for me, I think if you include presample observations in one test, do it in all the tests.

I'm inclined to agree, which is why I said that I'm leaning in that direction. It's not wrong to vary, but consistency is a highly desirable. And I don't like to change things unless there is a good reason. I'm going to sit on this one a bit and ponder whether it makes sense to make a change.

Ok, it was just my opinion :) But if one day you'll change your, signalize me, perhaps in this post.

I appreciate the opinion. I will followup if the change is made.

[edit: here's what I posted in a related thread

I'm inclined to line up all of the presample handling, but to do so in EViews 8. It's not a bug in the calculation, be we can and do strive for consistency in approaches as much as possible, and I think it best to correct this, but would rather not do it mid-release.

Thanks for your help.

]

Ok, thank you very much.