From svetosch@gmx.net Fri Mar 12 04:35:22 2010
From: Sven Schreiber <svetosch@gmx.net>
To: gretl-devel@gretlml.univpm.it
Subject: [Gretl-devel] restrict parsing problem
Date: Fri, 12 Mar 2010 10:34:52 +0100
Message-ID: <4B9A0ABC.7080903@gmx.net>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============5541006666213933011=="

--===============5541006666213933011==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

Hi,
the following mini-script:

<script>
open denmark
ols LRM const LRY IBO IDE
restrict
    b[LRY]*b[IBO] - 2*b[IDE]*b[LRY] = 0
end restrict
</script>

gives (excerpt):


? restrict
? b[LRY]*b[IBO] - 2*b[IDE]*b[LRY] = 0
? end restrict
Restriktion:
 b[LRY] - 2*b[IDE] = 0

I have now learned how to formulate nonlinear restrictions, so I know
the above is wrong, but I still think the
parsing is problematic. (Should throw an error instead.)

Also, I think it's a natural feature request to make the formulation of
nonlinear restrictions more intuitive. (I know they are a recent
addition and I'm grateful that it's possible at all, so I'm not saying
that it's urgent. But I guess I will put it in the feature request
tracker because of that.)

thanks,
sven


--===============5541006666213933011==--


From cottrell@wfu.edu Fri Mar 12 10:42:56 2010
From: Allin Cottrell <cottrell@wfu.edu>
To: gretl-devel@gretlml.univpm.it
Subject: Re: [Gretl-devel] restrict parsing problem
Date: Fri, 12 Mar 2010 10:42:55 -0500
Message-ID: <Pine.A41.4.58.1003121036210.151774@f1n11.sp2net.wfu.edu>
In-Reply-To: 4B9A0ABC.7080903@gmx.net
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============7511216202184869975=="

--===============7511216202184869975==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit


On Fri, 12 Mar 2010, Sven Schreiber wrote:

> the following mini-script:
>
> <script>
> open denmark
> ols LRM const LRY IBO IDE
> restrict
>     b[LRY]*b[IBO] - 2*b[IDE]*b[LRY] = 0
> end restrict
> </script>
>
> gives (excerpt):
>
>
> ? restrict
> ? b[LRY]*b[IBO] - 2*b[IDE]*b[LRY] = 0
> ? end restrict
> Restriktion:
>  b[LRY] - 2*b[IDE] = 0
>
> I have now learned how to formulate nonlinear restrictions, so I know
> the above is wrong, but I still think the
> parsing is problematic. (Should throw an error instead.)

OK, it now does so in CVS.

> Also, I think it's a natural feature request to make the formulation of
> nonlinear restrictions more intuitive. (I know they are a recent
> addition and I'm grateful that it's possible at all, so I'm not saying
> that it's urgent. But I guess I will put it in the feature request
> tracker because of that.)

If you do that, please include a detailed design suggestion.

Allin

--===============7511216202184869975==--


From svetosch@gmx.net Sat Mar 13 11:53:54 2010
From: Sven Schreiber <svetosch@gmx.net>
To: gretl-devel@gretlml.univpm.it
Subject: Re: [Gretl-devel] restrict parsing problem
Date: Sat, 13 Mar 2010 17:53:42 +0100
Message-ID: <4B9BC316.80501@gmx.net>
In-Reply-To: Pine.A41.4.58.1003121036210.151774@f1n11.sp2net.wfu.edu
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============4473506138642984984=="

--===============4473506138642984984==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

Allin Cottrell schrieb:
> On Fri, 12 Mar 2010, Sven Schreiber wrote:
> 
>> the following mini-script:
>>
>> <script>
>> open denmark
>> ols LRM const LRY IBO IDE
>> restrict
>>     b[LRY]*b[IBO] - 2*b[IDE]*b[LRY] = 0
>> end restrict
>> </script>
>>
>> gives (excerpt):
>>
>>
>> ? restrict
>> ? b[LRY]*b[IBO] - 2*b[IDE]*b[LRY] = 0
>> ? end restrict
>> Restriktion:
>>  b[LRY] - 2*b[IDE] = 0
>>
>> I have now learned how to formulate nonlinear restrictions, so I know
>> the above is wrong, but I still think the
>> parsing is problematic. (Should throw an error instead.)
> 
> OK, it now does so in CVS.
> 
>> Also, I think it's a natural feature request to make the formulation of
>> nonlinear restrictions more intuitive. (I know they are a recent
>> addition and I'm grateful that it's possible at all, so I'm not saying
>> that it's urgent. But I guess I will put it in the feature request
>> tracker because of that.)
> 
> If you do that, please include a detailed design suggestion.
> 

Well correct me if I'm wrong, but constructing the auxiliary restriction
function which returns a zero matrix under the null hypothesis is purely
algorithmic. So if you have a restriction as in the above example,

b[LRY]*b[IBO] - 2*b[IDE]*b[LRY] = 0

it directly translates into:

matrix h0 = b[1]*b[2]-2*b[3]*b[1]

(well the ordering of the coeffs needs to be taken into account of
course) and the rest is already implemented in gretl. And I think it's
completely ok to require that nonlinear restrictions should be given
with a zero on the right-hand side.

Is this what you had in mind in terms of comment to add in the tracker?

thanks,
sven

--===============4473506138642984984==--