1:31 a.m.
I'm trying to estimate SEMs using panel data, and the panel is unbalance,
could you tell me if it is possible?
12:41 a.m.
On Sat, 8 Aug 2009, Zhenzeng Young wrote:
I'm trying to estimate SEMs using panel data, and the panel is
unbalance, could you tell me if it is possible?
"SEM" = simultaneous equation models? So far I know this should
work, but I will admit that it's not seriously tested with panel
data.
Why don't you try it and let us know if you find any apparent
problems?
Allin Cottrell
10:53 a.m.
Dear Mr. Allin Cottrell,
I tried to estimate panel data simultaneous equation model, but failed as an
error message appeared, it says "Sorry, command not available for this
estimator".
I attached my dataset to this mail, and the information about the dataset
and equations is:
<info about data and equations>
113 cross-sectional units observed over 26 periods;
unbalanced panel data;
equation pf 0 gdpr ko pcr
equation pcr 0 gdpc efw to pf fdi
endog pf pcr
<info about data and equations>
I hope you can help me to solve the problem.
Thanks.
Zhenzeng YOUNG
2009/8/10 Allin Cottrell <cottrell(a)wfu.edu>
On Sat, 8 Aug 2009, Zhenzeng Young wrote:
> I'm trying to estimate SEMs using panel data, and the panel is
> unbalance, could you tell me if it is possible?
"SEM" = simultaneous equation models? So far I know this should
work, but I will admit that it's not seriously tested with panel
data.
Why don't you try it and let us know if you find any apparent
problems?
Allin Cottrell
_______________________________________________
Gretl-users mailing list
Gretl-users(a)lists.wfu.edu
http://lists.wfu.edu/mailman/listinfo/gretl-users
--
YANG Zhenzeng
Dep. of international economics and trade,
Economics school,
Tianjin University of Finance and Economics, PRC.
5:14 p.m.
On Mon, 10 Aug 2009, Zhenzeng Young wrote:
I tried to estimate panel data simultaneous equation model, but
failed as an error message appeared, it says "Sorry, command not
available for this estimator".
I attached my dataset to this mail, and the information about
the dataset and equations is...
Thanks for the test case. This was very helpful -- it exposed a
few bugs that are now fixed in CVS and the Windows snapshot at
http://ricardo.ecn.wfu.edu/pub/gretl/gretl_install.exe
This response is rather lengthy. but hopefully it may be helpful
to you and to others who may have run into similar problems.
First, the error message you got -- "Sorry, command not available
for this estimator" -- was wrong and misleading. The message
should have been, "Missing data encountered". (I had forgotten
that gretl rejects missing values when doing system estimation;
that's not a bug in itself, but the error-reporting was messed
up.)
We then want to limit the sample to non-missing observations to do
the system estimation. My script to handle this began as follows:
<script>
open fin_dev_v1.csv
# register the panel structure
setobs 26 1.1 --stacked-time-series
list sysvars = pf gdpr ko pcr gdpc efw to fdi
smpl sysvars --no-missing
</script>
The idea was to make a list of all the variables used in the
system equations, then sample with the "--no-missing" option to
cut out the rows with missing values for variables in the list.
This exposed two further issues. First, the word "to" is used by
gretl in constructing ranges of lags. So my command to set up the
list "sysvars" went wrong -- it was confused by your variable
named "to". My fix for issue this was to make "to" a reserved
word (that is, you are no longer allowed to call a variable "to").
OK, so I renamed "to" to "xto" in your CSV file and tried again.
Next problem: after doing
smpl sysvars --no-missing
there was still a problem with missing values. How could that be?
The trouble was that after sub-sampling, gretl was "helpfully"
trying to reconstitute a balanced panel by inserting some padding
rows. In most cases this is in fact helpful, but when the
"--no-missing" option is given with "smpl" it is clearly not
right. That is now fixed.
With the various fixes in place, the following will do system
estimation on your data:
<script>
open fin_dev_v1.csv --quiet
setobs 26 1.1 --stacked-time-series
# in case we want to keep track of panel structure
genr unit
genr time
list sysvars = pf gdpr ko pcr gdpc efw xto fdi
smpl sysvars --no-missing
pansys <- system
equation pf 0 gdpr ko pcr
equation pcr 0 gdpc efw xto pf fdi
endog pf pcr
end system
estimate pansys method=ols
estimate pansys method=tsls
estimate pansys method=3sls
</script>
Allin Cottrell
9:32 p.m.
On Mon, 10 Aug 2009, Allin Cottrell wrote (in response to
Zhenzeng Young):
[T]he word "to" is used by gretl in constructing ranges of
lags.
So my command to set up the list "sysvars" went wrong -- it was
confused by your variable named "to". My fix for issue this was
to make "to" a reserved word (that is, you are no longer allowed
to call a variable "to").
On second thoughts, there's no need to add "to" to the list of
reserved words. By coding a bit smarter I've removed the
ambiguity between "to" as variable name and "to" as lag range
indicator.
Allin.
1:35 p.m.
Allin Cottrell schrieb:
On Mon, 10 Aug 2009, Allin Cottrell wrote (in response to
Zhenzeng Young):
> [T]he word "to" is used by gretl in constructing ranges of lags.
> So my command to set up the list "sysvars" went wrong -- it was
> confused by your variable named "to". My fix for issue this was
> to make "to" a reserved word (that is, you are no longer allowed
> to call a variable "to").
On second thoughts, there's no need to add "to" to the list of
reserved words. By coding a bit smarter I've removed the
ambiguity between "to" as variable name and "to" as lag range
indicator.
nice and user-friendly effort of course, but isn't this very bug-prone?
just my 2€ct,
sven
8:05 p.m.
On Tue, 11 Aug 2009, Sven Schreiber wrote:
Allin Cottrell schrieb:
> On Mon, 10 Aug 2009, Allin Cottrell wrote (in response to
> Zhenzeng Young):
>
>> [T]he word "to" is used by gretl in constructing ranges of lags.
>> So my command to set up the list "sysvars" went wrong -- it was
>> confused by your variable named "to". My fix for issue this was
>> to make "to" a reserved word (that is, you are no longer allowed
>> to call a variable "to").
>
> On second thoughts, there's no need to add "to" to the list of
> reserved words. By coding a bit smarter I've removed the
> ambiguity between "to" as variable name and "to" as lag range
> indicator.
>
nice and user-friendly effort of course, but isn't this very bug-prone?
You have a point, but I think we're alright. I believe the
following illustrates the toughest case for disambiguation, and we
manage it OK. That is, L1 ends up holding 3 lags of QNC, while L2
holds the three variables "PRIME", "to" and "STOCK".
open data9-7
series to = QNC
list L1 = QNC(-1 to -3)
list L2 = 4 to 6
list L1 print
list L2 print
On the other hand, even if we're bug-free in this respect, the
command
list L2 = 4 to 6
kind of looks as if it might produce a list holding vars 4, 5 and
6 (although that syntax is not in fact supported). So perhaps
there's a case for banning "to" as a variable name for the sake of
readibility in scripts?
Allin.
12:05 p.m.
Allin Cottrell schrieb:
On Tue, 11 Aug 2009, Sven Schreiber wrote:
> Allin Cottrell schrieb:
>> On Mon, 10 Aug 2009, Allin Cottrell wrote (in response to
>> Zhenzeng Young):
>>
>>> [T]he word "to" is used by gretl in constructing ranges of lags.
>>> So my command to set up the list "sysvars" went wrong -- it was
>>> confused by your variable named "to". My fix for issue this was
>>> to make "to" a reserved word (that is, you are no longer allowed
>>> to call a variable "to").
>> On second thoughts, there's no need to add "to" to the list of
>> reserved words. By coding a bit smarter I've removed the
>> ambiguity between "to" as variable name and "to" as lag
range
>> indicator.
>>
> nice and user-friendly effort of course, but isn't this very bug-prone?
You have a point, but I think we're alright. I believe the
following illustrates the toughest case for disambiguation, and we
manage it OK. That is, L1 ends up holding 3 lags of QNC, while L2
holds the three variables "PRIME", "to" and "STOCK".
open data9-7
series to = QNC
list L1 = QNC(-1 to -3)
list L2 = 4 to 6
list L1 print
list L2 print
On the other hand, even if we're bug-free in this respect, the
command
list L2 = 4 to 6
kind of looks as if it might produce a list holding vars 4, 5 and
6 (although that syntax is not in fact supported). So perhaps
there's a case for banning "to" as a variable name for the sake of
readibility in scripts?
Yes my gut feeling is that if 'to' is a part of gretl's language, then
it should be reserved. The more I think about it, the stronger my
feeling gets, but still I'm not going to push it any further...
thanks,
sven
12:23 p.m.
On 12-08-2009, at 14:05, Sven Schreiber wrote:
> ..........
Yes my gut feeling is that if 'to' is a part of gretl's language, then
it should be reserved. The more I think about it, the stronger my
feeling gets, but still I'm not going to push it any further...
thanks,
sven
I agree with you.
As far as I am concerned either something is a reserved word or it
isn't.
It's safe and won't lead to weird errors.
Berend
5:37 p.m.
On Wed, 12 Aug 2009, Berend Hasselman wrote:
On 12-08-2009, at 14:05, Sven Schreiber wrote:
>> ..........
>
> Yes my gut feeling is that if 'to' is a part of gretl's language, then
> it should be reserved. The more I think about it, the stronger my
> feeling gets, but still I'm not going to push it any further...
>
> thanks,
> sven
I agree with you.
As far as I am concerned either something is a reserved word or it
isn't.
It's safe and won't lead to weird errors.
OK, I accept the point. I've made the change in CVS.
Allin.
5364
days inactive
5368
days old
9 comments
4 participants
participants (4)
-
Allin Cottrell -
Berend Hasselman -
Sven Schreiber -
Zhenzeng Young