Re: [Gretl-devel] '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