Hello,
I am working on NLS panel data model and wanted force 0<c(2)<1 condition in the estimation. So I input @Logit function transformation on c(2).
As a result it turned out that Estimation of a nonlinear equation by logit transformation of c(2) and without logit transformation gives same c(2) coefficient values. Is there a bug somewhere or am I missing something ? Would very much appreciate any comments on this.
Starting values for coefficient vector 15 :
0.058, 0.70, 0.80, 0.1, 0.90
In the workfile Frozen tables of estimation without logit : WITHOUT_LOGIT_ESTIMATION
with logit : LOGIT_ESTIMATION
Thank you..
acemi
Nonlinear Panel Least Squares Estimation Bug ?
Moderators: EViews Gareth, EViews Moderator
Nonlinear Panel Least Squares Estimation Bug ?
 Attachments

 simulasyon_eviews data_fi_forum.wf1
 (52.57 KiB) Downloaded 24 times

 EViews Developer
 Posts: 2555
 Joined: Wed Oct 15, 2008 9:17 am
Re: Nonlinear Panel Least Squares Estimation Bug ?
The NLLS specification in question is:
and the @logit in question appears in two places. Note that in both places, the @logit(c(2)) is multiplied by (1c(3)) and that c(3) appears nowhere else in the specification.
What is happening is that when you put @logit(C(2)) in the specification, the estimated C(2) is 3.475962 and the estimated C(3) is 0.011247. When you remove the @logit from the specification, the estimated C(2) is essentially the same, and the estimated C(3) changes to 0.724080, to account for the different C(2) multiplier.
In the former case, we have the product
@logit(3.475962020405048)*(10.01124694631085797) = 0.9590865294754549
In the latter case, we have the product
3.475964623707893*(10.7240803618384858)= 0.9590869012357059
Note that the numbers are not quite the same when we look at them at the highest precision, but you are right that they are effectively the same.
The bottom line is that C(3) is only identified jointly with its multiplier and that the nonlinear transformation of C(2) simply results in a rescaling of C(3) to match the desired product.
Code: Select all
log(y) = (((1exp(c(1)*@trend))*@logit(c(2))*(1c(3))*log(s))+((1exp(c(1)*@trend))*c(5)*log(l))+((1exp(c(1)*@trend))*c(4)*log(fi))+((1exp(c(1)*@trend))*log(gamma+(1c(2))*c(5)*n))+((1exp(c(1)*@trend))*@logit(c(2))*(1c(3))*log((n+delta)+(c(5)*n)))+((exp(c(1)*@trend))*log(y(1))))
and the @logit in question appears in two places. Note that in both places, the @logit(c(2)) is multiplied by (1c(3)) and that c(3) appears nowhere else in the specification.
What is happening is that when you put @logit(C(2)) in the specification, the estimated C(2) is 3.475962 and the estimated C(3) is 0.011247. When you remove the @logit from the specification, the estimated C(2) is essentially the same, and the estimated C(3) changes to 0.724080, to account for the different C(2) multiplier.
In the former case, we have the product
@logit(3.475962020405048)*(10.01124694631085797) = 0.9590865294754549
In the latter case, we have the product
3.475964623707893*(10.7240803618384858)= 0.9590869012357059
Note that the numbers are not quite the same when we look at them at the highest precision, but you are right that they are effectively the same.
The bottom line is that C(3) is only identified jointly with its multiplier and that the nonlinear transformation of C(2) simply results in a rescaling of C(3) to match the desired product.

 EViews Developer
 Posts: 2555
 Joined: Wed Oct 15, 2008 9:17 am
Re: Nonlinear Panel Least Squares Estimation Bug ?
I should also point that this would not occur if the restriction were placed on all of the C(2) in the specification. I'm not sure if this was intended, but all of the C(2) effects are not constrained. In particular, restricting the effect of C(2) in the log and exp functions would have more than a scaling effect.
Re: Nonlinear Panel Least Squares Estimation Bug ?
Thank you for your quick and detailed explanation.
1 Do you mean @logit((1exp(c(1)*@trend))*c(2))*((1c(3))*log(s)) + ... +@logit((1exp(c(1)*@trend))*c(2))*((1c(3))*log((n+delta)). Sorry I want to verify that I understood correctly your statement below. If this is so, then since whole purpose for @logit transformation is to impose/force limits for c(2) I guess it wouldnt be appropriate for my purpose.
2 The whole purpose for @logit transformation is to impose/force limits for c(2). For the @logit(c(2)) conversion, the estimation of c(2) is 3,475962 which is clearly not within intended range limits of 0<c(2)<1. So in order to obtain value for @logit(c(2)), substitute this value in 1/(1+exp(3,475962)) = 0,969996 which is between intended limits. But is it OK to conclude that I have constrained c(2) in this case ?
Thank you again and regards,
acemi
1 Do you mean @logit((1exp(c(1)*@trend))*c(2))*((1c(3))*log(s)) + ... +@logit((1exp(c(1)*@trend))*c(2))*((1c(3))*log((n+delta)). Sorry I want to verify that I understood correctly your statement below. If this is so, then since whole purpose for @logit transformation is to impose/force limits for c(2) I guess it wouldnt be appropriate for my purpose.
EViews Glenn wrote:I should also point that this would not occur if the restriction were placed on all of the C(2) in the specification. I'm not sure if this was intended, but all of the C(2) effects are not constrained. In particular, restricting the effect of C(2) in the log and exp functions would have more than a scaling effect.
2 The whole purpose for @logit transformation is to impose/force limits for c(2). For the @logit(c(2)) conversion, the estimation of c(2) is 3,475962 which is clearly not within intended range limits of 0<c(2)<1. So in order to obtain value for @logit(c(2)), substitute this value in 1/(1+exp(3,475962)) = 0,969996 which is between intended limits. But is it OK to conclude that I have constrained c(2) in this case ?
Thank you again and regards,
acemi

 EViews Developer
 Posts: 2555
 Joined: Wed Oct 15, 2008 9:17 am
Re: Nonlinear Panel Least Squares Estimation Bug ?
The coefficient C(2) in the original is replaced by @logit(C(2)) which is constrained to lie in 0, 1. So whenever you interpret the effect of the new C(2), you need to feed into the @logit function.
The statement before was to note that if you wanted to constrain C(2) everywhere to lie in 0, 1 that you need to replace *all* of the C(2) with @logit(C(2)). Then for whatever estimate of the C(2) you end up with, the *effective* coefficient, @logit(C(2)) will satisfy the limits.
The statement before was to note that if you wanted to constrain C(2) everywhere to lie in 0, 1 that you need to replace *all* of the C(2) with @logit(C(2)). Then for whatever estimate of the C(2) you end up with, the *effective* coefficient, @logit(C(2)) will satisfy the limits.
Re: Nonlinear Panel Least Squares Estimation Bug ?
Can you give a specific example about *all* of c(2) with @logit ? My interpretation was as follows marked in red:
@logit((1exp(c(1)*@trend))*c(2))*((1c(3))*log(s)) + ... +@logit((1exp(c(1)*@trend))*c(2))*((1c(3))*log((n+delta))
Thank you.
@logit((1exp(c(1)*@trend))*c(2))*((1c(3))*log(s)) + ... +@logit((1exp(c(1)*@trend))*c(2))*((1c(3))*log((n+delta))
EViews Glenn wrote:The statement before was to note that if you wanted to constrain C(2) everywhere to lie in 0, 1 that you need to replace *all* of the C(2) with @logit(C(2)). Then for whatever estimate of the C(2) you end up with, the *effective* coefficient, @logit(C(2)) will satisfy the limits.
Thank you.

 EViews Developer
 Posts: 2555
 Joined: Wed Oct 15, 2008 9:17 am
Re: Nonlinear Panel Least Squares Estimation Bug ?
No, just replace everywhere you have C(2) in the *original* specification with @logit(C(2)). You are simply replacing a coefficient, C(2), with an expression that depends on a coefficient but is functionally constrained to lie in the unit interval, @logit(C(2)).
Who is online
Users browsing this forum: No registered users and 2 guests