10:53 p.m.
Hello again,
is there any possibility to test a restriction of the kind
b[4]/b[2]=b[3]/b[2] using the wald-test?
If I read the manual correctly it does not seem to be implemented. Or
does there exist an alternative to test this kind of restriction?
cheers,
Artur
12:03 a.m.
Hi,
Using the estimated values for the coeffs., test:
(log(b[4])-log(b[2]))-log(b[3])=log(b[2]).
Rick
--------------------------------------------------
From: "artur tarassow" <artur.tarassow(a)googlemail.com>
Sent: Wednesday, August 05, 2009 7:53 PM
To: <gretl-users(a)lists.wfu.edu>
Subject: [Gretl-users] non-linear Wald-Test
Hello again,
is there any possibility to test a restriction of the kind
b[4]/b[2]=b[3]/b[2] using the wald-test?
If I read the manual correctly it does not seem to be implemented. Or
does there exist an alternative to test this kind of restriction?
cheers,
Artur
_______________________________________________
Gretl-users mailing list
Gretl-users(a)lists.wfu.edu
http://lists.wfu.edu/mailman/listinfo/gretl-users
Nenhum vírus encontrado nessa mensagem recebida.
Verificado por AVG - www.avgbrasil.com.br
Versão: 8.5.375 / Banco de dados de vírus: 270.13.45/2284 - Data de
Lançamento: 08/05/09 18:23:00
12:06 a.m.
That looks like b[4]=b[3] to me
P.
artur tarassow a écrit :
Hello again,
is there any possibility to test a restriction of the kind
b[4]/b[2]=b[3]/b[2] using the wald-test?
If I read the manual correctly it does not seem to be implemented. Or
does there exist an alternative to test this kind of restriction?
cheers,
Artur
_______________________________________________
Gretl-users mailing list
Gretl-users(a)lists.wfu.edu
http://lists.wfu.edu/mailman/listinfo/gretl-users
1:38 a.m.
On Thu, 6 Aug 2009, artur tarassow wrote:
is there any possibility to test a restriction of the kind
b[4]/b[2]=b[3]/b[2] using the wald-test?
If I read the manual correctly it does not seem to be implemented. Or
does there exist an alternative to test this kind of restriction?
Assuming you mean, b[4]/b[2] = b[3]/b[5] (or at least
something that does not reduce to b[4] = b[3]) ... no, you can't
do it with the standard Wald test.
One approach is to estimate (a) the unrestricted model and (b) the
non-linear model that results when the restriction is applied.
If the unrestricted model, was, say
u: y = b1 + b2x2 + b3x3 + b4x4 + b5x5 + e
then applying b4/b2 = b3/b5 gives the restricted model
r: y = b1 + b2x2 + b3x3 + (b2b3/b5)x4 + b5x5 + e
If the original model was estimated via OLS, the restricted one
could be estimated via NLS. Then construct an F-test based on the
difference between the restricted and unrestricted sums of squared
residuals.
An alternative is to apply an ML estimator (or maybe *LS is
already ML?) and use the restricted and unrestricted
log-likelihoods to form a Likelihood Ratio test: 2 * (llu - llr)
is asymptotically distributed as chi-square(1) in this example.
Allin Cottrell
2:09 a.m.
On Wed, 5 Aug 2009, Allin Cottrell wrote:
On Thu, 6 Aug 2009, artur tarassow wrote:
> is there any possibility to test a restriction of the kind
> b[4]/b[2]=b[3]/b[2] using the wald-test?
> If I read the manual correctly it does not seem to be implemented. Or
> does there exist an alternative to test this kind of restriction?
[ ... ]
If the original model was estimated via OLS, the restricted one
could be estimated via NLS. Then construct an F-test based on the
difference between the restricted and unrestricted sums of squared
residuals.
Hmm, actually you'd be on firmer ground using the chi-square form:
chi-square(J) = T * (SSRr - SSRu) / SSRu
where J = number of restrictions and T = sample size.
Allin Cottrell
9:13 a.m.
On Wed, 5 Aug 2009, Allin Cottrell wrote:
> If the original model was estimated via OLS, the restricted one
> could be estimated via NLS.
An alternative which does away with NLS and the associated potential
convergence problems is a Wald-type test, that is, a simple application
of the delta method (see section 5.9 of the manual). Example:
<script>
function nlWald(matrix coeff, matrix vcv, string funcstring)
lc = coeff
string s = funcstring~"(&lc)"
matrix bread = @s
df = cols(bread)
matrix J = fdjac(lc, @s)
matrix ham = invpd(qform(J, vcv))
scalar WT = qform(bread, ham)
printf "Nonlinear Wald Test: %12.6f (%d df, p-value = %g)\n", \
WT, df, pvalue(x, df, WT)
return scalar WT
end function
# ----------------------------------------------
# constraint function
function somestupidfunction(matrix *coeff)
scalar b1 = coeff[1]
scalar b2 = coeff[2]
matrix ret = (sqrt(b1)-b2*50) ~ (b1*b2 - 7)
return matrix ret
end function
# ----------------------------------------------
# main script
open data3-1.gdt
ols price const sqft
nlWald($coeff, $vcv, "somestupidfunction")
</script>
Basically, all you have to do is write a constraint function returning a
_row_ vector, which must be 0 under H0 and nonzero under H1. Then, you
feed it into the nlWald function and you're all set.
The example above tests the (silly) joint hypothesis
\sqrt{\beta_1} = 50 \beta_2
and
\beta_1 \beta_2 = 7
Riccardo (Jack) Lucchetti
Dipartimento di Economia
Università Politecnica delle Marche
r.lucchetti(a)univpm.it
http://www.econ.univpm.it/lucchetti
11:40 p.m.
On Thu, 6 Aug 2009, Riccardo (Jack) Lucchetti wrote:
On Wed, 5 Aug 2009, Allin Cottrell wrote:
>> If the original model was estimated via OLS, the restricted one
>> could be estimated via NLS.
An alternative which does away with NLS and the associated potential
convergence problems is a Wald-type test, that is, a simple application
of the delta method (see section 5.9 of the manual). Example:
<script>
function nlWald(matrix coeff, matrix vcv, string funcstring)
lc = coeff
string s = funcstring~"(&lc)"
matrix bread = @s
df = cols(bread)
matrix J = fdjac(lc, @s)
matrix ham = invpd(qform(J, vcv))
scalar WT = qform(bread, ham)
printf "Nonlinear Wald Test: %12.6f (%d df, p-value = %g)\n", \
WT, df, pvalue(x, df, WT)
return scalar WT
end function
# ----------------------------------------------
# constraint function
function somestupidfunction(matrix *coeff)
scalar b1 = coeff[1]
scalar b2 = coeff[2]
matrix ret = (sqrt(b1)-b2*50) ~ (b1*b2 - 7)
return matrix ret
end function
# ----------------------------------------------
# main script
open data3-1.gdt
ols price const sqft
nlWald($coeff, $vcv, "somestupidfunction")
</script>
Basically, all you have to do is write a constraint function returning a
_row_ vector, which must be 0 under H0 and nonzero under H1. Then, you
feed it into the nlWald function and you're all set...
This is certainly an elegant approach. In fact, I wonder if it
might be worth offering a semi-automated version as an option to
the existing "restrict" command. That is,
restrict <function-name> --<option-name>
where <function-name> would refer to something like your
somestupidfunction and <option-name> would be something like
"nl-Wald". The place of your "nlWald" function would be taken by
a built-in function that automatically accesses $coeff and $vcv
from the last-estimated model (and deposits $test and $pvalue).
Is this too much like spoon-feeding?
On the other hand, my reading in Greene and Davidson and MacKinnon
(and not, I hasten to say, my own unaided thinking!) leads me to
the idea that such Wald tests are not altogether reliable, since
the result can depend quite sensitively on just how the
restriction is represented.
That thought was behind my suggestion of estimating the restricted
model and comparing either the sum of squared residuals or the
log-likelihood with that of the unrestricted model. True enough,
it's not always straightforward to estimate the restricted model
(though I think it is in the sort of case that Arthur brought up).
I'm not sure what's best here. Any other thoughts?
Allin.
11:55 p.m.
On Thu, 6 Aug 2009, Allin Cottrell wrote:
On Thu, 6 Aug 2009, Riccardo (Jack) Lucchetti wrote:
> On Wed, 5 Aug 2009, Allin Cottrell wrote:
>
>>> If the original model was estimated via OLS, the restricted one
>>> could be estimated via NLS.
>
> An alternative which does away with NLS and the associated potential
> convergence problems is a Wald-type test, that is, a simple application
> of the delta method (see section 5.9 of the manual).
...
> Basically, all you have to do is write a constraint function
returning a
> _row_ vector, which must be 0 under H0 and nonzero under H1. Then, you
> feed it into the nlWald function and you're all set...
This is certainly an elegant approach. In fact, I wonder if it
might be worth offering a semi-automated version as an option to
the existing "restrict" command. That is,
restrict <function-name> --<option-name>
where <function-name> would refer to something like your
somestupidfunction and <option-name> would be something like
"nl-Wald". The place of your "nlWald" function would be taken by
a built-in function that automatically accesses $coeff and $vcv
from the last-estimated model (and deposits $test and $pvalue).
Is this too much like spoon-feeding?
Not at all, if you ask me. In fact it'd be a very valuable addition.
On the other hand, my reading in Greene and Davidson and MacKinnon
(and not, I hasten to say, my own unaided thinking!) leads me to
the idea that such Wald tests are not altogether reliable, since
the result can depend quite sensitively on just how the
restriction is represented.
Yes, this is true. However, it's a finite-sample phenomenon. It's exactly
the same problem you have when you write a GMM orthogonality condition in
two equivalent ways and you end up with widely different estimates. It's a
fact of life, I'm afraid. On the other hand, it's a nice tool to have and
if you feel your sample is too small, you're free to use other approaches.
Riccardo (Jack) Lucchetti
Dipartimento di Economia
Università Politecnica delle Marche
r.lucchetti(a)univpm.it
http://www.econ.univpm.it/lucchetti
3:45 p.m.
Follow-up in regard to Jack's nice presentation of the delta
method for testing nonlinear restrictions.
This is not documented yet (nor finalized, if people have good
suggestions for changes) but in CVS we have the following option
for the "restrict" command:
restrict
rfunc = <function-name>
end restrict
That is, you can use the keyword "rfunc" to indicate that you're
giving a constraint function rather than explicit statement of a
restriction. As in Jack's script, this function should take as
its single argument the coefficient vector (in "pointer" form),
and it should return a vector that is zero under H0, non-zero
under the alternative.
At present this is available only for single-equation models.
And the "rfunc" option cannot be combined with restrictions given
in any other form within the same "restrict" block.
Here's an example, in the neighborhood of Arthur T's question,
testing whether two pairs of parameter values have a common ratio:
<script>
function restr (matrix *b)
matrix ret = b[1]/b[2] - b[4]/b[5]
return matrix ret
end function
open data4-10
ols 1 0 2 3 4 5
restrict
rfunc = restr
end restrict
</script>
Allin Cottrell
5:22 p.m.
Hi,
Is there any command in gretl to obtained grouped descriptive statistics
based on a dummy or a discrete variable (without passing through "smpl
--restrict" command) ?
best,
artur
11:52 a.m.
On Fri, 7 Aug 2009, artur bala wrote:
Hi,
Is there any command in gretl to obtained grouped descriptive statistics
based on a dummy or a discrete variable (without passing through "smpl
--restrict" command) ?
<script>
open mroz87
summary WA --by=LFP
</script>
Riccardo (Jack) Lucchetti
Dipartimento di Economia
Università Politecnica delle Marche
r.lucchetti(a)univpm.it
http://www.econ.univpm.it/lucchetti
2:03 p.m.
Am 07.08.2009 17:45, Allin Cottrell schrieb:
Follow-up in regard to Jack's nice presentation of the delta
method for testing nonlinear restrictions.
This is not documented yet (nor finalized, if people have good
suggestions for changes) but in CVS we have the following option
for the "restrict" command:
restrict
rfunc = <function-name>
end restrict
That is, you can use the keyword "rfunc" to indicate that you're
giving a constraint function rather than explicit statement of a
restriction. As in Jack's script, this function should take as
its single argument the coefficient vector (in "pointer" form),
and it should return a vector that is zero under H0, non-zero
under the alternative.
At present this is available only for single-equation models.
And the "rfunc" option cannot be combined with restrictions given
in any other form within the same "restrict" block.
Here's an example, in the neighborhood of Arthur T's question,
testing whether two pairs of parameter values have a common ratio:
<script>
function restr (matrix *b)
matrix ret = b[1]/b[2] - b[4]/b[5]
return matrix ret
end function
open data4-10
ols 1 0 2 3 4 5
restrict
rfunc = restr
end restrict
</script>
Certainly a very nice feature!
Why is the pointer form necessary?
thanks,
sven
6:44 p.m.
On Sat, 8 Aug 2009, Sven Schreiber wrote:
Am 07.08.2009 17:45, Allin Cottrell schrieb:
> Follow-up in regard to Jack's nice presentation of the delta
> method for testing nonlinear restrictions.
>
> This is not documented yet (nor finalized, if people have good
> suggestions for changes) but in CVS we have the following option
> for the "restrict" command:
>
> restrict
> rfunc = <function-name>
> end restrict
>
> That is, you can use the keyword "rfunc" to indicate that you're
> giving a constraint function rather than explicit statement of a
> restriction. As in Jack's script, this function should take as
> its single argument the coefficient vector (in "pointer" form),
> and it should return a vector that is zero under H0, non-zero
> under the alternative...
Certainly a very nice feature!
Why is the pointer form necessary?
Ah, it's not actually necessary, though it is a bit more
efficient. However, we do need to standardize on pointer-form or
not. I suppose the straight, non-pointer form is more "natural".
Any thoughts?
Allin.
5:47 p.m.
On Sat, 8 Aug 2009, Allin Cottrell wrote:
On Sat, 8 Aug 2009, Sven Schreiber quoted:
> > That is, you can use the keyword "rfunc" to indicate that you're
> > giving a constraint function rather than explicit statement of a
> > restriction. As in Jack's script, this function should take as
> > its single argument the coefficient vector (in "pointer" form),
> > and it should return a vector that is zero under H0, non-zero
> > under the alternative...
and replied:
>
> Certainly a very nice feature!
>
> Why is the pointer form necessary?
And I reponded:
Ah, it's not actually necessary, though it is a bit more
efficient. However, we do need to standardize on pointer-form or
not. I suppose the straight, non-pointer form is more "natural".
Fixed in CVS. The signature for the callback function for a
nonlinear restriction, in the context of the "restrict" command,
should now be:
function foo (const matrix m)
(replace "foo" and "m" as desired).
This is linked to a general modification of the effect of the
"const" qualifier for matrix arguments: if you promise not to
modify a matrix argument then you get the matrix "directly", not a
copy. That is, it's the same, speed-wise, as passing a "pointer
to matrix" (but it's an error if you try to modify the argument).
I think the business of using the pointer formulation purely for
speed-up in gretl was potentially a bit confusing; it's no longer
necessary for matrices, just use "const" instead.
Allin
8:46 p.m.
Am 09.08.2009 19:47, Allin Cottrell schrieb:
This is linked to a general modification of the effect of the
"const" qualifier for matrix arguments: if you promise not to
modify a matrix argument then you get the matrix "directly", not a
copy. That is, it's the same, speed-wise, as passing a "pointer
to matrix" (but it's an error if you try to modify the argument).
I think the business of using the pointer formulation purely for
speed-up in gretl was potentially a bit confusing; it's no longer
necessary for matrices, just use "const" instead.
sounds good!
thanks,
sven
5367
days inactive
5371
days old
14 comments
7 participants
participants (7)
-
Allin Cottrell -
artur bala -
artur tarassow -
Pierre Chaussé -
Ricardo Gonçalves Silva -
Riccardo (Jack) Lucchetti -
Sven Schreiber