12:47 p.m.
Hi,
one of these questions that could have been asked years ago:
The 'hausman' command does a very specific thing, namely test a _pooled_
OLS specification in panel data. In contrast, the better-known Hausman
test of RE vs. FE, and also that of OLS vs. IV/TSLS is automatically
done if applicable.
Why then isn't the Hausman test after pooled OLS done automatically as
well? And related: Why are there no $test and $pvalue accessors after
the 'hausman' command? (At least it's not in the doc.)
My preference would be to deprecate the 'hausman' command, do the test
of the pooled specification automatically, and extend the $hausman
accessor to that case.
Opinions?
thanks,
sven
3:34 p.m.
New subject: 'modtest' extensions (was: Why a separate 'hausman' command?)
Am 19.09.2017 um 14:47 schrieb Sven Schreiber:
The 'hausman' command does a very specific thing, namely test
a _pooled_
OLS specification in panel data. In contrast, the better-known Hausman
test of RE vs. FE, and also that of OLS vs. IV/TSLS is automatically
done if applicable.
Why then isn't the Hausman test after pooled OLS done automatically as
well? And related: Why are there no $test and $pvalue accessors after
the 'hausman' command? (At least it's not in the doc.)
My preference would be to deprecate the 'hausman' command, do the test
of the pooled specification automatically, and extend the $hausman
accessor to that case.
Opinions?
I believe that now right after the release (of 2017d) is a good time to
discuss this further. Actually I would suggest to consolidate more
diagnostic commands into 'modtest':
# instead of 'cusum':
modtest --cusum [--squares --quiet]
# instead of 'qlrtest':
modtest --qlrtest [--limit-to=... --plot=... --quiet]
# instead of 'reset':
modtest --reset [--squares-only --cubes-only --quiet --silent]
# and again the 'hausman' thing of the previous post
# (so this would automatically change its meaning,
# depending on whether it's invoked after 'tsls' or after 'panel'):
modtest --hausman [--nerlove --matrix_diff]
# instead of 'chow':
modtest --chow [--dummy=... --obs=... --limit-to=... --quiet]
Maybe there are even more instances where this consolidation would
apply. In my view it would be more intuitive and logical to have a
common interface for those diagnostic tests, given that we already have
'modtest' but that it is currently somewhat arbitrary and path-dependent
which specific tests it covers.
cheers,
sven
7:21 p.m.
New subject: 'modtest' extensions (was: Why a separate 'hausman' command?)
On Fri, 10 Nov 2017, Sven Schreiber wrote:
Am 19.09.2017 um 14:47 schrieb Sven Schreiber:
> The 'hausman' command does a very specific thing, namely test a _pooled_
> OLS specification in panel data. In contrast, the better-known Hausman test
> of RE vs. FE, and also that of OLS vs. IV/TSLS is automatically done if
> applicable.
>
> Why then isn't the Hausman test after pooled OLS done automatically as
> well? And related: Why are there no $test and $pvalue accessors after the
> 'hausman' command? (At least it's not in the doc.)
>
> My preference would be to deprecate the 'hausman' command, do the test of
> the pooled specification automatically, and extend the $hausman accessor to
> that case.
>
> Opinions?
I think of the "hausman" command as an exploratory thing. If you
want to estimate a panel-data model but have no a priori idea of
which estimator is likely to be suitable you _might_ find it helpful
to try pooled OLS plus "hausman". (Or perhaps more likely, do the
GUI equivalent, via /Tests/Panel diagnostics after OLS). But if you
want the relevant accessors you'd estimate fixed or random effects.
I believe that now right after the release (of 2017d) is a good time
to
discuss this further. Actually I would suggest to consolidate more diagnostic
commands into 'modtest':
# instead of 'cusum':
modtest --cusum [--squares --quiet]
# instead of 'qlrtest':
modtest --qlrtest [--limit-to=... --plot=... --quiet]
# instead of 'reset':
modtest --reset [--squares-only --cubes-only --quiet --silent]
# and again the 'hausman' thing of the previous post
# (so this would automatically change its meaning,
# depending on whether it's invoked after 'tsls' or after 'panel'):
modtest --hausman [--nerlove --matrix_diff]
# instead of 'chow':
modtest --chow [--dummy=... --obs=... --limit-to=... --quiet]
Maybe there are even more instances where this consolidation would apply. In
my view it would be more intuitive and logical to have a common interface for
those diagnostic tests, given that we already have 'modtest' but that it is
currently somewhat arbitrary and path-dependent which specific tests it
covers.
I take your last point here, but there's a practical limitation. We
only have so many option flags available (at present, as many as
there are letters in the Roman alphabet) and I think we might be
struggling to avoid collisions if we merge in several additional
tests that each has an array of options of its own. I'd need to
check, but I suspect we'd have to switch to syntax along the lines
of
modtest --test=autocorr <specific options>
modtest --test=heterosked <specific options>
and so on, where the choice of diagnostic becomes an option
parameter rather than an option as such. And then backward
compatibility would be difficult to arrange.
[Of course, in principle we could have a practically unlimited
number of distinct option flags, but it would mean a fairly
substantial internal redesign to allow more than 26, and a bigger
redesign to allow more than the number of bitflags that fit into a
32-bit integer.]
Allin
10:20 p.m.
New subject: 'modtest' extensions
Am 11.11.2017 um 20:21 schrieb Allin Cottrell:
On Fri, 10 Nov 2017, Sven Schreiber wrote:
> Am 19.09.2017 um 14:47 schrieb Sven Schreiber:
I think of the "hausman" command as an exploratory thing.
If you want to
estimate a panel-data model but have no a priori idea of which estimator
is likely to be suitable you _might_ find it helpful to try pooled OLS
plus "hausman".
I see, but I don't think that this is very relevant, frankly. When
people have a panel dataset, they usually ponder the question RE or FE.
I think it's very rare that people consider a pooled specification from
the start.
> have 'modtest' but that it is currently somewhat
arbitrary and
> path-dependent which specific tests it covers.
I take your last point here, but there's a practical limitation. We only
have so many option flags available (at present, as many as there are
letters in the Roman alphabet) and I think we might be struggling to
avoid collisions if we merge in several additional tests that each has
an array of options of its own.
You mean because the first letter of an option is automatically its
short form? Couldn't that simply be forbidden in these cases? Or if this
is not the point, I don't understand the problem I'm afraid.
[Of course, in principle we could have a practically unlimited number
of
distinct option flags, but it would mean a fairly substantial internal
redesign to allow more than 26,
Yeah I agree that 26 should be enough. But I'm kind of confident that
that wouldn't be a real limitation somehow.
thanks,
sven
7:35 p.m.
New subject: 'modtest' extensions
Am 11.11.2017 um 23:20 schrieb Sven Schreiber:
Am 11.11.2017 um 20:21 schrieb Allin Cottrell:
> On Fri, 10 Nov 2017, Sven Schreiber wrote:
>> have 'modtest' but that it is currently somewhat
arbitrary and
>> path-dependent which specific tests it covers.
>
> I take your last point here, but there's a practical limitation. We
> only have so many option flags available (at present, as many as there
> are letters in the Roman alphabet) and I think we might be struggling
> to avoid collisions
You mean because the first letter of an option is automatically its
short form?
OK, I can see that already with 'qlrtest' there would be a clash with
the 'q' from 'quiet'.
OTOH, looking at the modtest options there are some with the same
starting letter: autocorr/arch, squares/silent, etc. So I guess I don't
really understand the technical problem!?
Also, honestly I think it is unfortunate that because of this the
diagnostic tests are split into two groups in a quite ad-hoc way that is
difficult to communicate. (At least I didn't understand it before!)
As an interim remedy we might add to the built-in doc for 'modtest' a
sentence like this:
"For other diagnostic tests after estimation (which require more option
flags) see cusum, qlrtest, reset, hausman, chow."
cheers,
sven
9:45 p.m.
New subject: 'modtest' extensions
On Mon, 13 Nov 2017, Sven Schreiber wrote:
Am 11.11.2017 um 23:20 schrieb Sven Schreiber:
> Am 11.11.2017 um 20:21 schrieb Allin Cottrell:
>> On Fri, 10 Nov 2017, Sven Schreiber wrote:
>>> have 'modtest' but that it is currently somewhat arbitrary and
>>> path-dependent which specific tests it covers.
>>
>> I take your last point here, but there's a practical limitation. We only
>> have so many option flags available (at present, as many as there are
>> letters in the Roman alphabet) and I think we might be struggling to avoid
>> collisions
> You mean because the first letter of an option is automatically its short
> form?
OK, I can see that already with 'qlrtest' there would be a clash with the
'q'
from 'quiet'.
OTOH, looking at the modtest options there are some with the same starting
letter: autocorr/arch, squares/silent, etc. So I guess I don't really
understand the technical problem!?
Sorry for the delay in responding, but here we go...
No, the first letter of an option is not necessarily its short form.
In case of conflict in that regard we cast around for another letter
that does not conflict in context. For example, the autocorr option
to modtest bags 'a' and the arch option gets 'h'. If a given command
takes a large number of options it can become kinda difficult to
find an unused letter, but that in itself is not a show-stopper.
There follows an explanation of the main constraint.
1) We represent option flags internally using a C enumeration or
"enum", which provides an easy and efficient way to associate a set
of symbolic constants with integer values. The C enum type is
guaranteed to be "big enough" to hold a (4-byte, 32-bit) "int".
2) A 32-bit integer can represent up to 2^32 distinct values, but...
while some gretl options are mutually exclusive in certain contexts
others are complementary, so we have to allow for distinct option
flags coexisting in our 32-bit integer. That means we have at most
32 independent options in our enum (each commanding 1 bit). We want
to reserve one of these to represent "this option is not yet set",
so that leaves 31. Right now we represent 26 of these by the
symbolic constants OPT_A,OPT_B,..., OPT_Z. This is important for the
(at least semi-)comprehensibility and maintainability of the code:
we want, for example, to be able to refer to the "robust" option
flag as OPT_R, rather than as some unmemorable large integer.
3) We could add a few more symbolic constants (say,
OPT_A1,OPT_B1,...) but we'd soon run out of those (and the flags in
question wouldn't have a single-letter abbreviation, but maybe
that's no big loss). The 32-bit limitation still binds, unless we go
over to a bigger and more complex representation of option flags.
4) We've actually already hit the practical limit on option flags in
at least one case, the "gnuplot" command. That's because in addition
to user-visible options (of which there are many) we use the option
argument to gnuplot() to pass some internal state information. That
was the rationale for getting rid of the old distinct option flags
for different "fit" options in favor of a single option flag,
--fit=whatever, which takes a number of parameters.
Also, honestly I think it is unfortunate that because of this the
diagnostic
tests are split into two groups in a quite ad-hoc way that is difficult to
communicate. (At least I didn't understand it before!)
As an interim remedy we might add to the built-in doc for 'modtest' a
sentence like this:
"For other diagnostic tests after estimation (which require more option
flags) see cusum, qlrtest, reset, hausman, chow."
I agree. We can look into the practicality of folding more tests
into the "modtest" command. And if we can't fit them all in, we
should surely do the appropriate cross-referencing in the help doc.
Allin
7:39 p.m.
New subject: Back to Hausman (was: Re: 'modtest' extensions)
Am 11.11.2017 um 20:21 schrieb Allin Cottrell:
> Am 19.09.2017 um 14:47 schrieb Sven Schreiber:
>
>> The 'hausman' command does a very specific thing, namely test a
>> _pooled_ OLS specification in panel data.
>> as well? And related: Why are there no $test and $pvalue
accessors
>> after the 'hausman' command? (At least it's not in the doc.)
/Tests/Panel diagnostics after OLS). But if you want the relevant
accessors you'd estimate fixed or random effects.
... except that you still don't have a way to get the result of the
Hausman test of pooled vs. RE (or FE) in a script, do you?
Hence my suggestion to extend the $hausman accessor to the pooled panel
case.
thanks,
sven
2909
days inactive
2964
days old
6 comments
2 participants
participants (2)
-
Allin Cottrell -
Sven Schreiber