EViews.com

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 1-5 :
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

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 (1-c(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)*(1-0.01124694631085797) = 0.9590865294754549

In the latter case, we have the product

3.475964623707893*(1-0.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.

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.

Thank you for your quick and detailed explanation.

1- Do you mean @logit((1-exp(-c(1)*@trend))*c(2))*((1-c(3))*log(s)) + ... +@logit((1-exp(-c(1)*@trend))*c(2))*((1-c(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.

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

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.

Can you give a specific example about *all* of c(2) with @logit ? My interpretation was as follows marked in red:

@logit((1-exp(-c(1)*@trend))*c(2))*((1-c(3))*log(s)) + ... +@logit((1-exp(-c(1)*@trend))*c(2))*((1-c(3))*log((n+delta))

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.

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)).