Panel data wooldridge autocorrelation test

[Peter Sutton]

Hello all,

I am trying to run wooldridge test for autocorrelation on panel data.

However, is this possible with interaction using the factor notation and interaction?

And if so, why not?

Best,
Peter

[Carlo Lazzaro]

Peter:
as per the community-contributed module -xtserial- help file, factor variable notation is not supported.
Hence, you have to calculate interactions by hand.

[Peter Sutton]

Hi carlo, thanks for your reply.

Is there any formulae in stata to do this? It seems very time-consuming if I am correct but please correct me if wrong

[Jeff Wooldridge]

It's actually easier, and even better, to implement the test "by hand." One thing I don't like about xtserial is that you can't see how practically important the rejection of the null is. My proposal was to use a t test and then you can actually see how far the estimate deviates from -0.5. This would be easy to do using the differencing operator but, regrettably, you can't use D.() with factor notation, either. (This makes no sense and I hope Stata fixes this in Stata 18. If I start with a model that has interactions then, for estimation, I want to difference everything, including the interactions. Here's what does work without factor notation:

xtset unit_id time_id
reg D.(y x1 ... xk time_2 ... time_T), vce(cluster unit_id)
predict ehat, resid
reg ehat L.ehat, vce(cluster unit_id)

The t statistic on L.ehat is the test that you want. If you square it, you get the F-type statistic reported by xtserial. Note that the first clustering option is to get proper standard errors for the beta hats but has no effect on the serial correlation test.

Here's what should be allowed:

xtset unit_id time_id
reg D.(y x1 ... xk c.x1#c.x2 i.x3#c.x2 i.time_id)
predict ehat, resid
reg ehat L.ehat, vce(cluster unit_id)

Unfortunately, Stata doesn't currently get this correct even for the term c.x1#c.x2 if one of the variables is time constant. So for now, you have to compute all of the interactions you want in the model "by hand." And then use the first differencing regression.

[Sebastian Kripfganz]

This problem has bitten me in some of my programs before. The problem is that Stata expands D.(c.x1#c.x2) to cD.x1#cD.x2, which is not what we want. Given that this is a specific feature of Stata rather than a bug, to avoid backward-compatibility issues I doubt that StataCorp will change this behavior in the future.

[Jeff Wooldridge]

Hi Sebastian: I understand what you mean about backward compatibility, but I would characterize what Stata is doing as producing the wrong results. They're changing the researcher's model. So I hope they seriously consider changing how D.() operates. For example, in the T = 2 panel data case, if first differencing doesn't always reproduce fixed effects -- as it won't any any model that contains an interaction between two time-varying variables -- then that will cause more confusion than any issues with backward compatibility.