Panel data regression

[Rafal Krol]

Hello everyone,
I would like to kindly ask how to solve my problem with Panel data using a rolling 60 month window. This is my sample data (there is unique crsp_portnos with average of 200 month of age)


input double(crsp_portno crsp_fundno) float(mofd portret)
1000001 4273 373 .123
1000001 4273 374 .124
1000001 4273 375 .125
1000001 4273 376 .126
1000001 4273 377 .127
1000001 4273 378 .128
1000001 4273 379 .129
1000001 4275 373 .123
1000001 4275 374 .124
1000001 4275 375 .125
1000001 4275 376 .126
1000001 4275 377 .127
1000001 4275 378 .128
1000001 4275 379 .129

end
[/CODE]

As you can see crsp_portno consists of different crsp_fundnos. Thus, in a certain month there could 1, 2 or more observations when a crsp_portno has 1, 2 or more crsp_fundnos in a certain month. Now, to run the xtreg command I need to overcome repeated time values within panel to use -xtset crsp_portno datecode. I run -egen datecode=group(mofd)- and then -rangestat (xtreg) portret mkt, interval(datecode -59 0) by(crsp_portno) excludeself- , but the information I receive back is <istmt>: 3499 xtreg() not found. I thought I could just run duplicates drop crsp_portno mofd, force, but with the line I lose observations that include some other information for unique crsp_fundno in certain month. Could you tell me how to overcome this problem? Could it be the reason that the data in unbalanced?

To overcome <istmt>: 3499 xtreg() not found, I have just uploaded STATA but nothing has changed, and xtreg is still not working

Best regards,
Rafał

[Rafal Krol]

Ok nevermind... with rangestat one just simply run -reg- instead -xtreg... Sorry for that.
Still I would like to kindly ask how to get around -duplicates drop crsp_portno mofd, force- problem for my crsp_portnos? Since I don't use the xtreg, should I abandon the idea with xtset?

Best,
Rafał

[Carlo Lazzaro]

Rafal:
provided that you're not intended to use time-series operators such as lags and leads, the usual fix is to -xtset- your dataset with -panelid- only.

[Rafal Krol]

Dear Carlo,
In fact, I intend to use lags, but later in the analysis

[Rafal Krol]

Dear Carlo,
In fact, I intend to use lags, but later in the analysis.

[Carlo Lazzaro]

Rafal:
if you plan to include lagged variables in the right-hand side of your -xtreg- equation, then the suggested fix won't work.
You should be more detailed -timevar-, if feasible.

[Nick Cox]

Going back to #1: The code reported as problematic includes

rangestat (xtreg) portret mkt, interval(datecode -59 0) by(crsp_portno) excludeself

on which I will comment as second author.

This code is based on a profound misunderstanding of rangestat -- which is from SSC, as you are asked to explain.

As the help for rangestat implies, this will work if and only if xtreg() is the name of a Mata function, which you would need to write yourself because there is no such function in official Mata. or bundled with rangestat. In effect the error message is saying the same thing:. Mata can't find the code for xtreg() because it doesn't exist, so that failure within Mata is fatal to your rangestat call. . Uploading Stata once again won't help because a second copy of Stata doesn't contain the code any more than the first did.

Otherwise put, this syntax is not a way to call up arbitrary Stata commands, such as xtreg, from within rangestat.

Unfortunately, the problem can't be solved by simply supplying the missing code. Given an interest in lagged predictors, as Carlo Lazzaro also flags, you want in effect to apply xtreg where it does not apply, i.e. with multiple observations for some (identifier, time) pairs. That is the difficulty to confront.

It is much harder for me to suggest a sensible analysis, and not just because I don't work in this field. As you sense, dropping duplicates on identifier and year is no use because they typically differ on the variables of direct interest and so you would be throwing away interesting data capriciously. Perhaps there is a sensible analysis based on a collapse to distinct (identifier, time) pairs, but you'd need to think what that might be.

[Clyde Schechter]

Rafal,

Either you do not understand your data set or you have not thought through what kind of analysis you will do with your data. You were hoping to -xtset crsp_portno mofd- and then run analyses involving lags. So you are looking to "get around" the limitation that -xtset- will not allow duplicate values of crsp_portno and mofd. There is no way to get around this limitation. It's not some limitation of the software. It's a limitation of the very concept of lags. Consider in your example data, you have two observations with crsp_portno = 1000001 and mofd = 373. Which of those would be "the lag" for an observation with crsp_portno = 1000001 and mofd = 374? Both are equally good candidates and there is no way Stata can rationally pick between them. In other words, the reason Stata is giving you this error message is that in this setting lags are not definable.

Now, looking at your example data, there is a solution that suggests itself to me, but it may or may not be suitable for your research goals, or it may be relying on a pattern that holds in the example data but not in your real data set. In the example data, the combination of crsp_portno and crsp_fundno does, along with mofd, uniquely identify observations. And although -xtset- does not allow you to specify both crsp_portno and crsp_fundno as the panel variable, nothing stops you from creating a new variable that corresponds to the combination of crsp_portno and crsp_fundno.

egen panelid = group(crsp_portno crsp_fundno)
xtset panelid mofd

will work (in your example data, at least).

Now, before you just do this, you have to be sure that for the purpose of answering your research questions an analysis which treats the pair of crsp_portno and crsp_fundno as the "panel variable" is appropriate. As that is both a substantive question and one that depends on your specific, undisclosed, research questions, that is left to you.

[Rafal Krol]

Dear Clyde, Nick, and Carlo
Thank you very much for your valuable comments, and sorry for taking your time for this unsubstantive question. I am very grateful that you still pay a lot of effort to help me. I am trying to replicate a tough (for me) study, to later run my own analysis. Since I am not an expert in STATA, I ask stupid questions, maybe because I misunderstand consecutive steps in their paper. Sorry once again.

I will get myself together and next time ask better questions, after doing in depth research and making sure I am 100% certain in my needs.

[Carlo Lazzaro]

Rafal:
there are no (with some exceptions) stupid questions, but simply issues that search for an answer.
On this forum we're all fine with that because we all (it was my experience and for some Stata commands I'm not familiar with it still is) were newbies at a given point in time.
What the previous reply would like to convey is simply that clear (as far as feasible) question help everybody here and FAQ are really useful in this respect.
I do hope you enjoy participating in and contributing to this forum.

[Rafal Krol]

Thank you Carlo for your warm words. If I may, I will come back to the topic in the (close?) future, when I will have my questions clarified. Thank you.

[Carlo Lazzaro]

Rafal:
feel free to post (following the FAQ, please) when you consider you would reply to your query if you were not the original poster.
I would also recommend you to improve your knowledge of Stata commands for short and long panels, as they have so many different fearures for different research purposes.

[Rafal Krol]

That is what I am doing now Carlo. Working harder and harder to understand STATA!
Thank you again!