EViews.com

Hi,
Is there a bug in the Breakpoint Unit Root Test procedure? I noticed that, depending on the option selected for estimating the lag length (e.g. Akaike, Schwarz etc.), the value for probability can return a "NA". Has anyone else encountered this? (I'm using EViews 9.5.)
Thanks for any info,
Mike

Can you provide an example?

Can you provide an example?

Say, I specify a Breakpoint Unit Root Test. All the chosen fields are the same except I change the method for choosing lag length. When Schwarz is chosen, the probability for t-stat returns a "NA". All other methods for choosing lag length has a probability value.

Another example is, if the user fixes the lag length, from 1 to 7, there is a value for probability. Lag length of 8, 9, 10 returns a "NA". Then lag length of 11 and 12 both have a value for probability.

The data frequency is quarterly and sample is almost 80 data points after adjustments.

We'll need to have the actual data

Please see attached file. Series X1.
Specification of the breakpoint unit root test as follows:
Trend specification - trend & intercept
Break specification - trend & intercept
Lag length: fixed (probability of t-stat depends on lag - 1 to 4 OK; 5 NA; 6 & 7 OK; 8 to 10 NA; 11 & 12 OK)
Break type: additive outlier; Break point calculation: user specified 1998:4

As you can see, whether or not the t-stat has a probability value depends on the lag length chosen and it appears inconsistent.

The above is one example. The other example is as mentioned in my first post. Depending on the method chosen to estimate the lag length, the probability for the t-stat can return a "NA".

EViews advisors: any luck figuring out what's the problem? Is there a bug?
Thanks for your time on this.

A bug in the labeling of the p-value range. We weren't using the correct label in the "0.5 > p >= 0.10" case. You can see that you are > 0.1 by looking at the listed critical values and comparing with your statistic value.

We'll get this fixed.

Thank you very much for clarifying. I thought it may be something like that. Looking forward to the patch update to fix the bug.

Hi,
I know that in his original paper Perron(1989) used this test with a known and single breakpoint. Nevertheless, can we also use this test with multiple breakpoints by selecting Dickey-Fuller min-t, intercept break min-t, etc. when we select breakpoint selection method? If not, how can we conduct unit root test if we have multiple breakpoints in our model?
Thank you.

No. EViews only supports unit root tests with a single break point.