Clarification on Variable selection
by Lemma Tenessa
Dear GRTEL team;
I am trying to run a simultaneous equation model which is based on ordered
probit system. I have planned to approach this by two stage regression. As
you know two stage regression makes use of predicted values of endogenous
variables. So also predicted values can be either linear or categorical.
Now my question is which predicted value is advisable to consider ( the
linear or categorical) if my endogenous variables in the system of
equations are ordered latent variables.
I really thank you for any assistance which you might be able to provide.
With kind regards,
Tenessa L.
14 years, 2 months
Re: [Gretl-users] Threshold VAR: Coding Help
by Allin Cottrell
On Sat, 12 Mar 2011, Henrique Andrade wrote:
> Em 12 de mar�o de 2011 Allin escreveu:
>
> On Sat, 12 Mar 2011, Henrique Andrade wrote:
> >
> > > *Y(t) = X(t-1) + e1(t); if z(t-d)>=tau*
> > > *Y(t) = X(t-1) + e2(t); if z(t-d)<tau*
> >
> > If it's a TVAR I _think_ it should look more like
> >
> > Y_t = D1 + B1(L)Y_t + I_t*(D2 + B2(L)Y_t) + U_t
> >
> > where I_t = 1 if z(t-d) >= tau, otherwise 0.
> >
>
> Dear Allin, I need that the errors (and variances) differ in each regime:
>
> Y_t = D1 + B1(L)Y_t + U1_t, if z(t-d) >= tau
> Y_t = D2 + B2(L)Y_t + U2_t, otherwise
It seems to me that the error variances will automatically differ
across the two regimes in the version I constructed. But I'm not
experienced with TVARs so maybe I'm missing something.
> So I think I need to use the threshold values to build two data
> segments. To do this I'm doing something close to your script:
>
> * <script>*
> *series* z = normal()
> *scalar* tau = 1.5
> *series* r1 = z(-1) >= tau
> *series* r2 = 1-r1
> *loop foreach* i Y
> *series* r1$i = zeromiss(r1 * $i)
> *series* r2$i = zeromiss(r2 * $i)
> *endloop*
> *
> list regime1 = r1PAU r1IAU r1E
> list regime2 = r2PAU r2IAU r2E
> *
> *</scrip>*
>
> Now I just need to estimate two separate VARs [...]
It seems to me that estimating "two separate VARs" and estimating
one VAR with certain variables included conditionally (and
otherwise set to zero) amount to the same thing -- except, of
course, that in the version I gave, the D2 and B2 coefficients
must be interpreted as the (regime 2 minus regime 1) effect.
> But we have missing observations... How can we handle this?
I have no idea how this could work, in a time-series model with
lags. That's why I went for the combined version.
> Finally, I would like to make one more question. Looking at your
> original code, we have, in the last line, this expression: var
> 1 Y ; r2*. What the symbol "*" (in r2*) means?
OK, that's easy. The symbol "*" here is a "wildcard", so that
"r2*" denotes all series whose names start with "r2".
Allin
14 years, 2 months
Re: [Gretl-users] Threshold VAR: Coding Help
by Allin Cottrell
On Sat, 12 Mar 2011, Allin Cottrell wrote:
> On Sat, 12 Mar 2011, Henrique Andrade wrote:
>
> > Em 12 de mar�o de 2011 Allin escreveu:
> >
> > On Sat, 12 Mar 2011, Henrique Andrade wrote:
> > >
> > > > *Y(t) = X(t-1) + e1(t); if z(t-d)>=tau*
> > > > *Y(t) = X(t-1) + e2(t); if z(t-d)<tau*
> > >
> > > If it's a TVAR I _think_ it should look more like
> > >
> > > Y_t = D1 + B1(L)Y_t + I_t*(D2 + B2(L)Y_t) + U_t
> > >
> > > where I_t = 1 if z(t-d) >= tau, otherwise 0.
> > >
> >
> > Dear Allin, I need that the errors (and variances) differ in each regime:
> >
> > Y_t = D1 + B1(L)Y_t + U1_t, if z(t-d) >= tau
> > Y_t = D2 + B2(L)Y_t + U2_t, otherwise
>
> It seems to me that the error variances will automatically differ
> across the two regimes in the version I constructed. But I'm not
> experienced with TVARs so maybe I'm missing something.
Sorry, that response was too spineless. The errors and their
variances do differ in the formulation I gave, provided the
threshold hypothesis is correct.
I wrote the TVAR as
Y_t = D1 + B1(L)Y_t + I_t*(D2 + B2(L)Y_t) + U_t
where I_t = 1 if z(t-d) >= tau, otherwise 0.
We may rewrite this as
regime 1: U1_t = Y_t - (D1 + B1(L)Y_t)
regime 2: U2_t = Y_t - (D1 + B1(L)Y_t) - (D2 + B2(L)Y_t)
If D2 is non-zero and/or B2 is non-zero, the errors clearly differ
in the two regimes.
Allin
14 years, 2 months
Re: [Gretl-users] Threshold VAR: Coding Help
by Allin Cottrell
On Sat, 12 Mar 2011, Henrique Andrade wrote:
> *Y(t) = X(t-1) + e1(t); if z(t-d)>=tau*
> *Y(t) = X(t-1) + e2(t); if z(t-d)<tau*
If it's a TVAR I _think_ it should look more like
Y_t = D1 + B1(L)Y_t + I_t*(D2 + B2(L)Y_t) + U_t
where I_t = 1 if z(t-d) >= tau, otherwise 0.
In that case something like the following should do it:
<script>
open australia.gdt
list Y = PAU IAU E
# VAR without any regime-changing
var 1 Y
# make a fake threshold
series z = normal()
scalar tau = 1.5
series r2 = z(-1) >= tau
loop foreach i Y
series r2$i = r2 * $i(-1)
endloop
# VAR with regime changing
var 1 Y ; r2*
</script>
Allin Cottrell
14 years, 2 months
Threshold VAR: Coding Help
by Henrique Andrade
Dear Gretl Community,
I'm estimating a Threshold VAR model (TVAR) like this:
*Y(t) = X(t-1) + e1(t); if z(t-d)>=tau*
*Y(t) = X(t-1) + e2(t); if z(t-d)<tau*
Until now I was able to determine the delay parameter (*d*) and the
threshold value (*tau*). But I can't see how to estimate it with the "*var*"
command. Using RATS software with *australia.gdt* data I did:
<RATS commands>
system(model=regime1) 1 to 3
variables PAU IAU E
lags 1
deterministic constant
end(system)
estimate(smpl=(z{d}>=tau))
system(model=regime2) 1 to 3
variables PAU IAU E
lags 1
deterministic constant
end(system)
estimate(smpl=(z{d}<tau))
</RATS commands>
The line estimate(smpl=(z{d}>=tau)) tells RATS to estimate the VAR using
only the observations where the threshold variable (*z*) is equal or greater
than the threshold value (*tau*).
Could you please give some advice in order to "translate" these RATS code
into Gretl's scripting language?
Um abraço,
*Henrique C. de Andrade*
Doutorando em Economia Aplicada
Universidade Federal do Rio Grande do Sul
www.ufrgs.br/ppge
14 years, 2 months
Re: [Gretl-users] import data via odbc
by Allin Cottrell
On Fri, 11 Mar 2011, Leon Unger wrote:
> recently I tried to read in several series via odbc *including
> one dummy* series and I forgot to change its entries from "No"
> and "YES" to "0" and "1".
> However, SQL retrieved for all series the correct number of
> observations.*BUT ALL SERIES* were corrupted. That's why two
> thoughts come up:
>
> 1) I know from importing STATA files that GRETL changes string
> entries to number entries. Does GRETL use information provided
> by the STATA file, or does it this job by itself? If yes, would
> it be possible to add this functionality to the odbc read in
> process?
>
> 2) If one has always to provide numerical entries and e.g. one
> series is not correcltly specified then actually only this
> series should be corrupted.
As I said previously, I agree with Jack Lucchetti's comment that
getting an ODBC import right is really the responsbility of the
gretl user. But I also said that it was gretl's responsibility to
avoid crashing on an incorrect SQL query.
I've now investigated further, and I'm less inclined to think
there's a bug in gretl's handling of this issue.
Gretl can convert string-valued variables from Stata dta files
into numerical values because a dta file contains a clear
specification of the "original" type of each variable.
But things are different with ODBC. One uses the function
SQLBindCol() to tell ODBC what data type one wants from each data
column (and for all actual data columns gretl specifies the type
SQL_C_DOUBLE). It's then ODBC's job to convert whatever type comes
out of the db into what was requested.
As a test, I constructed a dummy db using mysql, with one "real"
numerical data column and one column containing "yes" and "no"
strings. I then used gretl to read in those two variables via
unixODBC. What I got was basically what you'd expect: the
numerical series came in OK, and the "yes"/"no" column came in as
a series of zeros (zero being the default when no numeric
conversion is possible).
If you're getting general data corruption when one of the data
columns contains strings, then (a) it might help if you were to
give us an exact recipe for reproducing the problem, but (b) maybe
your bug report should go to Microsoft Corp?
Allin Cottrell
14 years, 2 months
Re: [Gretl-users] import data via odbc
by Allin Cottrell
On Fri, 11 Mar 2011, Riccardo (Jack) Lucchetti wrote:
> On Fri, 11 Mar 2011, Leon Unger wrote:
>
> > recently I tried to read in several series via odbc including one dummy series and I forgot to change its entries
> > from "No" and "YES" to "0" and "1".
> > However, SQL retrieved for all series the correct number of observations. BUT ALL SERIES were corrupted.
> > That's why two thoughts come up:
> >
> > 1) I know from importing STATA files that GRETL changes string entries to number entries. Does GRETL use
> > information
> > provided by the STATA file, or does it this job by itself? If yes, would it be possible to add this functionality
> > to the odbc read in process?
> >
> > 2) If one has always to provide numerical entries and e.g. one series is not correcltly specified then actually
> > only this series should be corrupted.
>
> Of course everything is doable with enough time and resources. I also
> agree that automagic conversion of stuff coming from an ODBC connection
> would be very cool. However, the development of gretl is something that
> very few people do in their spare time. I don't mean to be rude, but
> asking the user to put a little extra care in formulating an SQL query
> doesn't sound unreasonable to me (especially considering that the user did
> not have to pay a single penny for the program).
Basically I agree with Jack, with one reservation: that is, the
attempt "blindly" to treat a string variable as if it were a
floating-point value would be likely to crash gretl (although
apparently that didn't happen in this particular case). And
crashing is always a bad policy. So even if we don't do an
automagical conversion of string-valued ODBC variables we should
at least flag an error and quit in this sort of case. I'll see
what we can do about that.
Allin Cottrell
14 years, 2 months
Re: [Gretl-users] import data via odbc
by Allin Cottrell
On Fri, 4 Mar 2011, Leon Unger wrote:
> in terms of importing data via odbc I encountered*strange
> behavior *of GRETL if using string labels instead of number
> labels [...]
It appears I was misinterpreting how SQLBindCol is supposed to
work for string fields. There's a modification in CVS and the
snapshots that (hopefully) should fix this problem.
Allin Cottrell
14 years, 2 months
Re: [Gretl-users] Reset of Dataset Structure.
by Allin Cottrell
On Thu, 10 Mar 2011, Austin Spry wrote:
> I have a custom data set in panel format using 'Trees' as
> Group/Unit index and 'Age' as the Time index. All 'Trees' also
> belong to one of 27 'Stands'.
>
> When I restrict the sample to a particular 'Stand', the data set
> structure does not transfer to the sample set. The 'Trees' and
> 'Age' indices must be reassigned every time I restrict the
> sample group. (The complete data set retains its specification
> as 'Panel Data' when I 'Restore Full Range'.)
>
> Am I doing something brainless here? Is there some reason GRETL
> keeps the entire data set as 'Panel' while changing each sample
> to 'Cross-Sectional'?
Hello Austin,
I don't suppose you are doing aything brainless, but I don't know
exactly what your dataset looks like, and on the face of it what
you are reporting is puzzling.
When you restrict the sample, starting from a panel dataset, gretl
checks to see if the restricted sample can still be interpreted as
a panel, and it drops back to a cross-sectional interpretation
only if the panel interpretation seems to be unavailable.
Obviously, a panel interpretation makes sense only if the
restricted sample still contains at least two groups and at least
two time periods.
By way of illustration, consider this gretl script (greene14_1 is
a panel dataset comprising 6 "units" or "groups" observed over 15
time periods):
open greene14_1.gdt
series foo = (unit==1 || unit==3)? 1 : 2
The "foo" series is intended to emulate your "Stand" variable. If
you now restrict the sample using "foo = 1" as criterion, you get
a panel with two groups, corresponding to the original "units" 1
and 3. If you restore the full sample then subsample using "foo =
2" as the criterion, you again get a panel, comprising the
original "units" 2, 4, 5 and 6.
If you're using a very old version of gretl this might not work as
described. The current version is 1.9.4.
Allin Cottrell
14 years, 2 months
Reset of Dataset Structure.
by Austin Spry
I have a custom data set in panel format using 'Trees' as Group/Unit index and 'Age' as the Time index. All 'Trees' also belong to one of 27 'Stands'.
When I restrict the sample to a particular 'Stand', the data set structure does not transfer to the sample set. The 'Trees' and 'Age' indices must be reassigned every time I restrict the sample group. (The complete data set retains its specification as 'Panel Data' when I 'Restore Full Range'.)
Am I doing something brainless here? Is there some reason GRETL keeps the entire data set as 'Panel' while changing each sample to 'Cross-Sectional'?
By the way, thank you so much for all your work on this project. GRETL has really allowed me to explore statistics. I really appreciate your efforts.
If I have posted in the wrong place, please let me know. I apologize for any inconvenience.
Austin
14 years, 2 months
