[Gretl-users] Re: questions about nonlinearity tests
Am 28.02.2021 um 01:05 schrieb Allin Cottrell:
On Sat, 27 Feb 2021, Sven Schreiber wrote:
> Am 23.02.2021 um 10:23 schrieb Sven Schreiber:
>
>> In the command reference for "modtest" I see two options labeled
"--logs
>> (nonlinearity, logs)" and "--squares (nonlinearity, squares)". But
the
>> description doesn't provide more information apart from being a LM-type
>> test. Is there more information somewhere?
Just for the record I'd say it's pretty obvious what the logs and
squares LM tests do, if you run an example.
That's true, after running the examples it's pretty clear.
My confusion partly arose because the label of nonlinearity&squares can
also be applied to a variant of the RESET test. Basically I had
forgotten that not all model specification tests are subsumed under
modtest.
> (Side remark: At the top of the file it says "library.c for
gretl --
> main interface to libgretl functions", so I don't understand why it
> lives under "gui" in the source tree. A hansl batch script on the CLI
> would also seem to use this.)
In that context "gretl" means the GUI program, as opposed to gretlcli.
The CLI programs gretlcli and gretlmpi have their own interfaces to
libgretl, which have to differ in various ways. Nothing but the GUI
program uses, or could use, gui/library.c.
Aha, good to know. I guess then the other interface is in
lib/src/libglue.c? What does it mean to execute a script in the GUI
script editor, does that count as GUI or as CLI in this context?
> I guess it would be useful if we could include the popular BDS
test:
> Brock, Dechert and Scheinkman (1987) (and later published as Brock,
> Dechert, Scheinkman and LeBaron, 1996; apparently there is some C code
> by LeBaron from 1997, LeBaron, B.(1997). “A Fast Algorithm for the BDS
> Statistic”, Studies in Nonlinear Dynamics and Econometrics, 2, 53-59,
> but maybe not necessary?)
>
> Getting a hansl prototype is not too difficult per se, but there are
> some other input parameters for the test which are somewhat arbitrary it
> seems.
Could be worthwhile, but it would be nice to know how best to select the
"somewhat arbitrary" parameters.
Right. The R function bds.test basically computes all variants in the
specified ranges.
(https://www.rdocumentation.org/packages/tseries/versions/0.10-48/topics/b...)
The Python statsmodels implementation seems to use a recommended
distance value by default, but also calculates with a range of the
embedding dimension.
(https://www.statsmodels.org/stable/_modules/statsmodels/tsa/_bds.html#bds)
The statsmodels thing probably relies on an old paper by Kanzler (1999,
SSRN-id151669) that contains some recommendations about the parameters
(apart from Matlab code). But the issue in general remains a bit murky I
guess.
guidance one can get from a rejection on the BDS test, other than
just
"there's something nonlinear going on". But closer study might be rewarded.
Yes, it's an omnibus test principle. But for example after fitting an
ARMA model as the most general linear filter, all the other nonlinearity
tests are off the table (and rightly greyed out in gretl's Tests menu --
OK granted, you could count the ARCH test as a nonlinear thing). The BDS
test would still be applicable.
Computational burden still is an issue today, however. R (and Eviews,
and probably Matlab) use compiled code, statsmodels appears to use
vectorized code. Of course the whole thing feels a bit like reinventing
the wheel, maybe in the short term a wrapper around R's tsa would be an
option?
thanks
sven