On Thu, 31 Jan 2008, Sven Schreiber wrote: The same applies to mle. It seems quite clear to me that only the --wald form should be allowed (in these cases, automatic estimation of the restricted model would involve quite a bit of work). I guess in principle this could be done, once we overcome a slight problem of notation: we may adopt a convention by which b3 is $coeff[3] and so on, like we do with, say, ols. Note, however, that this may be confusing in some cases, since gmm & mle allow you to put your parameters under arbitrary names. Example (admittedly a bit contrived): <script> nulldata 100 x = normal() y = x + normal() ols y 0 x scalar b1 = 0 scalar b2 = 0 matrix W = I(2) series e gmm e = y - b1 - b2*x orthog e ; const orthog e ; x weights W params b2 b1 end gmm </script> If, at this point, you were allowed to test a restriction for "b1 = 0", you wouldn't be testing the hypothesis of zero intercept, but rather of zero slope, since $coeff[1] is the _slope_, but comes first in the ordering of the "params" statement. On the other hand, a Wald-type statistic for restrictions of the kind $R \theta = d$ can be computed quite easily, considering that after gmm you _do_ have the $coeff and $vcv accessors ready to use. Example: <script> function Wald_type(matrix b, matrix V, matrix R, matrix d) matrix num = R*b - d matrix den = invpd(qform(R,V)) scalar wt = qform(num', den) return scalar wt end function </script> But I agree that having "restrict" work after gmm/mle would be nice. Actually, if we decide to devote some time to "restrict", it'd be rather cool to handle nonlinear constraints via the delta method. The problem is, this would probably force us introduce a few backward-incompatible changes. Riccardo (Jack) Lucchetti Dipartimento di Economia Università Politecnica delle Marche r.lucchetti(a)univpm.it http://www.econ.univpm.it/lucchetti

On Thu, 31 Jan 2008, Sven Schreiber wrote: The reason is that the parsing of the lines between "restrict" and "end restrict" is, at present, specifically tailored for what we have today, and it's not easy to extend. For example, you can't do something like my_own_special_value = 2 restrict b1 + my_own_special_value * b2 = 0 end restrict The reason is that _inside a restrict block_, normal parsing does not occur: rather, the string "b1" is mechanically translated into "element #1 of the coeff vector inside the last estimated model"; what you're suggesting would imply that, upon encountering the string "b1", the machinery goes: "first check if b1 can be interpreted as a non-missing scalar on the basis of the existing variables and functions; if not, fall back to $coeff[1]". Believe me, it's difficult. It can be done, but it ain't easy. And frankly, I'd rather spend my time implementing something that is _not_ there now (kalman, for example) or fixing bugs rather than making something _already there_ more convenient. Please note that if the above "generalised parsing" inside restrict was functional, it wouldn't take much longer to implement the delta method. Riccardo (Jack) Lucchetti Dipartimento di Economia Università Politecnica delle Marche r.lucchetti(a)univpm.it http://www.econ.univpm.it/lucchetti