Dear Sven,
> eval urcpval($test, $nobs, 1, 3)
> eval urcpval(abs($test), $nobs, 1, 3) # same
do
eval $test
Since $test > 0 this is the only expected result
H0: a series has unit root
Most macro indicators have unit roots, the result is expected
t-stats in ADF test under H0 has distribution which
is a functional of the standard Wiener process, so Student's is irrelevant
There are no such thing as two-sided ADF test
The variant you used is by far not the best one
Use GUI to auto-detect lag length
To reproduce GUI version in script the
default max lag length should be entered manually
This example does not indicate any anomalities
Oleh
Am 05.11.18 um 16:53 schrieb Allin Cottrell:
> On Mon, 5 Nov 2018, Sven Schreiber wrote:
>
>>>
>> Well, is a p-value a probability?
>
> I think it's best described as: the probability, conditional on H0
> being true, of obtaining a test statistic as unfavorable to the null
> as the one actually observed, or more so.
I'm not against it. (As I said from the beginning, p-values can be
philosophically tricky, and one-sided tests, too.)
However, this still leaves the wrong result of urcpval(0,0,1...). I
think your definition also says it should be 1. Or to put it
differently: The current output can only be justified with your
definition if at the same time you consider explosive values (possibly
far away from 1) as _less_ unfavorable to the unit root H0 than the H0
value of 1 itself. I don't think we'd want that.
>
> One could argue that if the test statistic is not even prima facie
> unfavorable to the null (on the wrong side of the distribution), the
> antecedent is not fulfilled and the p-value is therefore undefined.
Right. I think that's an important difference with one-sided tests,
where we cannot just focus on the null and forget about the rest.
I mean, one _could_ do the whole thing as a two-sided test, also
allowing explosion under the null. Obviously the null distribution would
be asymmetric. But that would also affect the critical values to the
left (stationary) side, because a part of the prob mass of the rejection
region would have to be shifted to the right.
(I'm not sure in the end / right now what gretl is actually doing
effectively.)
> But before changing gretl's behavior I'd want to take a look at what
> other software does in this sort of case.
>
That is certainly wise.
thanks,
sven
_______________________________________________
Gretl-devel mailing list
Gretl-devel@lists.wfu.edu
http://lists.wfu.edu/mailman/listinfo/gretl-devel