2:53 a.m.
Thanks Allin.
It was my mistake of not recognizing the coeffsum is a restriction with only 1 d.o.f.
While we are on the topic of wish-list,
1. Why can’t we make the robust standard error as the default on the GUI check box?
Is there any situation in which a robust standard error will be biased and wrong?
By having the default being robust, those that insist on having the homoskedastic standard
errors reported can uncheck the check box.
2. Is there any reason not to have time dummies included as the default in a panel data
regression? Those that have variables that only change with time should uncheck the
include time dummy check box.
Fred
On Mar 28, 2019, at 12:00 AM, gretl-users-request(a)lists.wfu.edu
wrote:
Send Gretl-users mailing list submissions to
gretl-users(a)lists.wfu.edu
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.wfu.edu/mailman/listinfo/gretl-users
or, via email, send a message with subject or body 'help' to
gretl-users-request(a)lists.wfu.edu
You can reach the person managing the list at
gretl-users-owner(a)lists.wfu.edu
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Gretl-users digest..."
Today's Topics:
1. Any way to make coeffsum quiet? (Fred Engst)
2. Re: Any way to make coeffsum quiet? (Sven Schreiber)
----------------------------------------------------------------------
Message: 1
Date: Wed, 27 Mar 2019 08:09:43 +0800
From: Fred Engst <engst.uibe(a)gmail.com>
To: gretl-users(a)lists.wfu.edu
Subject: [Gretl-users] Any way to make coeffsum quiet?
Message-ID: <27B73AC4-E584-4FBB-999F-6EAB467CEE30(a)gmail.com>
Content-Type: text/plain; charset=utf-8
Thanks Allin so much for such a quick response and fix to the crash report.
Relating to the coeffsum and restrict command block, however, I have a few questions.
1. In my script, I need to make the coeffsum be quiet, but that seems not to be an
option. Would it be hard to add one?
2. Coeffsum gives a t-test reading while the restrict gives an F-test result. I prefer
the t-test result for it gives me the sign of the sum, but shouldn?t both be an F-test?
Thanks,
Fred
> On Mar 27, 2019, at 12:00 AM, gretl-users-request(a)lists.wfu.edu wrote:
>
> Send Gretl-users mailing list submissions to
> gretl-users(a)lists.wfu.edu
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://lists.wfu.edu/mailman/listinfo/gretl-users
> or, via email, send a message with subject or body 'help' to
> gretl-users-request(a)lists.wfu.edu
>
> You can reach the person managing the list at
> gretl-users-owner(a)lists.wfu.edu
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Gretl-users digest..."
>
>
> Today's Topics:
>
> 1. Re: gretl crashed with a message of "Abort trap: 6 "
> (Allin Cottrell)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Tue, 26 Mar 2019 09:51:31 -0400 (EDT)
> From: Allin Cottrell <cottrell(a)wfu.edu>
> To: Gretl list <gretl-users(a)lists.wfu.edu>
> Subject: Re: [Gretl-users] gretl crashed with a message of "Abort
> trap: 6 "
> Message-ID: <alpine.LNX.2.21.1903260949320.16110@robroy>
> Content-Type: text/plain; charset="utf-8"; Format="flowed"
>
> On Tue, 26 Mar 2019, Fred Engst wrote:
>
>> My beloved gretl crashed on me. (:
>> My scrip was doing great for that last year until I added a line with the
coeffsum command.
>> It repeatedly crashed over and over again.
>> So I setup a small test dataset and invoked gretlcli, and it seems that coeffsum
worked the first time, and crashed the 2nd time with an error message of "Abort trap:
6?.
>> What did I do wrong?
>>
>> Here are the files that you might need to replicate the situation and help me
out:
>> 1. a test dataset,
>> 2. the scrip that crashes gretlcli
>> 3. the log from gretlcli
>> 4. two crash reports when I did run gretl & gretlcli.
>
> Thanks, Fred, for the detailed report. The problem is now fixed in git
> and snapshots. In "coeffsum" (and in "restrict" more generally)
we
> were not setting aside enough space for very long variable names.
>
> Allin
>
> ------------------------------
>
> _______________________________________________
> Gretl-users mailing list
> Gretl-users(a)lists.wfu.edu
> http://lists.wfu.edu/mailman/listinfo/gretl-users
>
> End of Gretl-users Digest, Vol 146, Issue 20
> ********************************************
------------------------------
Message: 2
Date: Wed, 27 Mar 2019 07:53:33 +0100
From: Sven Schreiber <svetosch(a)gmx.net>
To: gretl-users(a)lists.wfu.edu
Subject: Re: [Gretl-users] Any way to make coeffsum quiet?
Message-ID: <4325199a-1eb6-88b5-66fa-faf2b6940dd5(a)gmx.net>
Content-Type: text/plain; charset=utf-8; format=flowed
Am 27.03.2019 um 01:09 schrieb Fred Engst:
> Relating to the coeffsum and restrict command block, however, I have
> a few questions. 1. In my script, I need to make the coeffsum be
> quiet, but that seems not to be an option. Would it be hard to add
> one?
I agree that would be useful, similar to what has been added to (almost)
all similar commands over the past years.
(According to the reference it seems that the following test commands
still do not have such an option: hausman, meantest, runs, vartest,
possibly vif.)
2. Coeffsum gives a t-test reading while the restrict gives an
> F-test result. I prefer the t-test result for it gives me the sign of
> the sum, but shouldn?t both be an F-test?
The tests are totally equivalent since the F version has just 1 d.o.f.:
<hansl>
open hall
ols consrat const ewr vwr
coeffsum ewr vwr
eval $test^2 # the F version
restrict
b(ewr) + b(vwr) = 0
end restrict
</hansl>
Notice the identical p-values.
cheers
sven
------------------------------
_______________________________________________
Gretl-users mailing list
Gretl-users(a)lists.wfu.edu
http://lists.wfu.edu/mailman/listinfo/gretl-users
End of Gretl-users Digest, Vol 146, Issue 21
********************************************
9:50 p.m.
On Fri, 29 Mar 2019 at 02:54, Fred Engst <engst.uibe(a)gmail.com> wrote:
Thanks Allin.
It was my mistake of not recognizing the coeffsum is a restriction with
only 1 d.o.f.
While we are on the topic of wish-list,
1. Why can’t we make the robust standard error as the default on the
GUI check box?
Is there any situation in which a robust standard error will be biased and
wrong?
By having the default being robust, those that insist on having the
homoskedastic standard errors reported can uncheck the check box.
I would think that it is better to not have the robust standard error as
default. I would ask one to always first estimate the equation assuming
that the variance was homoskedastic. Then one should test for
homoskedasticity. If heteroskedasticity is found one should then consider
if the model was misspecified. (It is possible that other specification
tests also fail). If you are satisfied that the model is properly
specified you could then use the robust standard error.
2. Is there any reason not to have time dummies included as the
default in a panel data regression? Those that have variables that only
change with time should uncheck the include time dummy check box.
Not ticking the box completes a one-way panel estimation of the model.
ticking the box give a two-way estimate. I think that this is the proper
way to proceed and would not be in favor of the proposal
Fred
John C Frain
3 Aranleigh Park
Rathfarnham
Dublin 14
Ireland
www.tcd.ie/Economics/staff/frainj/home.html
mailto:frainj@tcd.ie
mailto:frainj@gmail.com
2:17 p.m.
On Sat, 30 Mar 2019, John C Frain wrote:
On Fri, 29 Mar 2019 at 02:54, Fred Engst <engst.uibe(a)gmail.com>
wrote:
> While we are on the topic of wish-list,
> 1. Why can’t we make the robust standard error as the default on the
> GUI check box?
> Is there any situation in which a robust standard error will be biased and
> wrong?
> By having the default being robust, those that insist on having the
> homoskedastic standard errors reported can uncheck the check box.
I would think that it is better to not have the robust standard
error as default. I would ask one to always first estimate the
equation assuming that the variance was homoskedastic. Then one
should test for homoskedasticity. If heteroskedasticity is found
one should then consider if the model was misspecified. (It is
possible that other specification tests also fail). If you are
satisfied that the model is properly specified you could then use
the robust standard error.
I agree with John on this. However, anyone who disagrees is free to
select the option "Use robust covariance by default", under the HCCME
tab in /Tools/Preferences/General.
As for whether robust standard errors are wrong in some way when the
errors are iid, one can experiment with the following script. It seems
that HC0 and HC1 (at least) often give standard errors that are too
small (and less accurate than the default classical ones).
<hansl>
set verbose off
nulldata 80 # make this bigger if you wish
series x = normal()
K = 10000 # replications
matrix B = zeros(K, 1)
matrix SE = zeros(K, 4)
loop i=1..K -q
series y = 10 + 2*x + normal()
ols y 0 x -q
B[i] = $coeff[2]
SE[i,1] = $stderr[2]
set hc_version 0
ols y 0 x -q -r
SE[i,2] = $stderr[2]
set hc_version 1
ols y 0 x -q -r
SE[i,3] = $stderr[2]
set hc_version 2
ols y 0 x -q -r
SE[i,4] = $stderr[2]
endloop
matrix X = {const, x}
matrix V = inv(X'X)
se0 = sqrt(V[2,2])
printf "\nPopulation s.d. of slope coeff: %.4f\n", se0
scalar se1 = sdc(B)
printf "Empirical s.d. of slope coeff: %.4f\n\n", se1
matrix altse = meanc(SE)
cnameset(altse, "deflt HC0 HC1 HC2")
printf "Means of estimated standard errors:\n\n%10.4f\n", altse
</hansl>
Allin
4:46 p.m.
On Thu, 4 Apr 2019, Allin Cottrell wrote:
On Sat, 30 Mar 2019, John C Frain wrote:
> On Fri, 29 Mar 2019 at 02:54, Fred Engst <engst.uibe(a)gmail.com> wrote:
>
>> While we are on the topic of wish-list,
>> 1. Why can’t we make the robust standard error as the default on the
>> GUI check box?
>> Is there any situation in which a robust standard error will be biased and
>> wrong?
>> By having the default being robust, those that insist on having the
>> homoskedastic standard errors reported can uncheck the check box.
>
> I would think that it is better to not have the robust standard error as
> default. I would ask one to always first estimate the equation assuming
> that the variance was homoskedastic. Then one should test for
> homoskedasticity. If heteroskedasticity is found one should then consider
> if the model was misspecified. (It is possible that other specification
> tests also fail). If you are satisfied that the model is properly
> specified you could then use the robust standard error.
I agree with John on this. However, anyone who disagrees is free to select
the option "Use robust covariance by default", under the HCCME tab in
/Tools/Preferences/General.
I think this is a very good read. Highly recommended:
https://gking.harvard.edu/files/gking/files/robust_0.pdf
-------------------------------------------------------
Riccardo (Jack) Lucchetti
Dipartimento di Scienze Economiche e Sociali (DiSES)
Università Politecnica delle Marche
(formerly known as Università di Ancona)
r.lucchetti(a)univpm.it
http://www2.econ.univpm.it/servizi/hpp/lucchetti
-------------------------------------------------------
1849
days inactive
1855
days old
3 comments
4 participants
participants (4)
-
Allin Cottrell -
Fred Engst -
John C Frain -
Riccardo (Jack) Lucchetti