EViews.com

Hi,

I am doing some unit root testing using the KPSS test.

When selecting the HAC variance in this test I can select the Bartlett window and set the user specified value of of the bandwidth to 1. This will use the autocovariance at lags zero (i.e. the varaince) and one (the first autocovariance) in the computation of the test. The formula for K in equation (37.21) in the EViews 9.5 documentation hence seem to be K(j/(l+1)). The command for this would be:

y.uroot(kpss, hac=bt, bw=1)

However, if I want to use the lrvar command to get the long-run variance that is used in the KPSS test, then I need to set the bandwidth to 2 in order to replicate the variance estimate. Hence, it seems as if the calculation of the kernel now uses K(j/l). The command for this would be:

y.lrvar(bw=2)

Have I understood this correctly? If so, how am I to think of this aspect logically?

Best,
Kristian

Your interpretation is almost correct. The short answer is that the KPSS test parameterizes the kernel in terms of lag truncation while the lrvar parameterizes in terms of bandwidth. With respect to what you wrote, note that in KPSS it is "K(j/(l+1))" as you wrote, but that in the lrvar case, it is not "K(j/l)", but is instead "K(j/b)" as you are specifying b in the expression j/b. Equivalence between the two obviously requires l+1 = b.

You ask for the logic behind this...

The difference between the older KPSS implementation and the newer lrvar computation is that the original KPSS paper was parameterized using the approach described by Newey-West in which one specified a lag truncation parameter l for the Bartlett kernel. In general, in a kernel estimator one specifies a bandwidth b in the expression K(j/b), but Newey-West, in dealing with this special case, parameterized the bandwidth in terms lag truncation with l+1 = b. The Newey-West parameterization is the approach taken by the early literature and EViews followed this approach when KPSS was implemented some time ago. I believe that Newey-West call their parameter a bandwidth, but it really is a lag truncation parameter.

More recently, when we implemented our long-run variance routine, we decided to allow for a wide variety of kernels. In so doing, we followed Andrews in allowing real valued bandwidths and kernels that do not have a natural lag truncation interpretation. As we saw it, the only natural way to do this is to have users specify the bandwidth for kernels directly, even though this differed from Newey-West's lag truncation interpretation.

In designing EViews we often have to make principled choices of this sort to accommodate different parts of the literature that disagree on how things should be specified. In this case we went for consistent generality in the lrvar computation so that the user always was working with the bandwidth, and not the bandwidth in some cases, and the lag truncation parameter in other cases. Consequently, when working with the kernel functions in lrvar you will always specify the bandwidth, but in some cases, you may need to think carefully about the relationship between lag truncation and bandwidth.

As we knew that this parameterization difference was potentially puzzling, we did provide a fairly detailed discussion of the relationship between bandwidth and lag truncation in the Appendix discussion of the long-run variance calculation (in the "Nonparametric Kernel" sub-section labeled "Bandwidth"). There are only a few paragraphs there, but I think it is worth a look.

The ultimate paragraph in this section summarizes the issue:

The varying relationship between the bandwidth and the lag-truncation parameter implies that one should examine the kernel function when choosing bandwidth values to match computations that are quoted in lag truncation form. For example, matching Newey-West’s (1987) Bartlett kernel estimator which uses m weighted autocovariance lags requires setting b_T = m + 1. In contrast, Hansen’s (1982) or White’s (1984) estimators, which sum the first m unweighted autocovariances, should be implemented using the Truncated kernel with b_T = m.

Great, I see.

Thank you for the superb answer.

/Krille

Glenn has been waiting for this question for years...

So long that I'd forgotten the answer...