Stata The Stata listserver
[Date Prev][Date Next][Thread Prev][Thread Next][Date index][Thread index]

Re: st: Problems Stochastic Frontier Analysis


From   "Scott Merryman" <[email protected]>
To   <[email protected]>
Subject   Re: st: Problems Stochastic Frontier Analysis
Date   Tue, 3 Feb 2004 19:55:11 -0600

Erik,

Are you sure Limdep converged?  Sometimes, I have found it necessary to increase
the maximum number of iterations in order to ensure convergence in Limdep.
Taking the xtfrontier1 data set (-webuse xtfrontier1-) and using the first 10
observations (-frontier lnwidgets lnworkers lnmachines in 1/10,
dist(exponential)-)  I was able to create similar results - very small standard
errors and large z-statistics.  Estimating the same model in Limdep, produced
'reasonable' looking standard errors, but at the top of the output was:

"DFP iterations - current estimate of sigma is nonpositive.
Line search does not improve fn. Exit iterations. Status=3
Abnormal exit from iterations. If current results are shown
check convergence values shown below. This may not be a
solution value (especially if initial iterations stopped).
Gradient value: Tolerance= .1000D-05, current value= .3550D+02
Function chg. : Tolerance= .0000D+00, current value= .1118D-02
Parameters chg: Tolerance= .0000D+00, current value= .1043D+04"

As an addition point to the one David raised about model misspecification:  in
your output, sigma_v is nearly 0 and therefore lambda is nearly infinite.  This
indicates that the compound error term is dominated by the one-sided error.
Essentially, you have estimated a deterministic cost frontier model.  All
variation in total expenditures not explained by variations in output quantity
and input prices is due to cost inefficiency.  In your model, there is no luck
or other external factors explaining the variation in cost.

Scott


----- Original Message ----- 
From: "David M. Drukker, StataCorp" <[email protected]>
To: <[email protected]>
Sent: Tuesday, February 03, 2004 12:32 PM
Subject: RE: st: Problems Stochastic Frontier Analysis


> Erik Brouwer <[email protected]> estimated a stochastic frontier model
> in Stata and obtained large z-statistics.
>
> Specifically, the estimation command
>
> . frontier lnTK lnZT, d(e) cost;
>
> produced
>
> Stoc. frontier normal/exponential model           Number of obs   = 15
>                                                   Wald chi2(1)    = 1.115e+12
> Log likelihood =  8.5130782                       Prob > chi2     = 0.0000
>
> ------------------------------------------------------------------------------ 
>         lnTK |      Coef.   Std. Err.      z    P>|z|     [95% Conf.
Interval]
> -------------+---------------------------------------------------------------- 
>         lnZT |   1.244566   1.18e-06        .   0.000     1.244563  1.244568
>        _cons |  -4.327623   .0000181        .   0.000    -4.327659  -4.327588
> -------------+---------------------------------------------------------------- 
>     /lnsig2v |  -39.73655   977.6138    -0.04   0.968    -1955.824  1876.351
>     /lnsig2u |  -3.135077   .5163978    -6.07   0.000    -4.147198  -2.122956
> -------------+---------------------------------------------------------------- 
>      sigma_v |   2.35e-09   1.15e-06                             0  .
>      sigma_u |   .2085579   .0538494                      .1257324  .3459441
>       sigma2 |   .0434964   .0224614                     -.0005272  .08752
>       lambda |   8.87e+07   .0538494                      8.87e+07  8.87e+07
> ------------------------------------------------------------------------------ 
> Likelihood-ratio test of sigma_u=0: chibar2(01) = 7.84   Prob>=chibar2 = 0.003
>
> Some of the z-statistics are missing because their corresponding standard
> errors are so small.
>
> The pattern of extremely small and very large standard errors indicates that
> the Hessian is not well-conditioned at the point which the algorithm has
> converged.  An ill-conditioned Hessian implies that the parameters are not
> well-identified by the data for this model.
>
> As discussed by Drukker and Wiggins (2004), Erik might want to begin dealing
> with this problem by checking that all of the variables are on about the
> same scale.  Simply rescaling the variables could produce a
> better-conditioned Hessian and eliminate the problem of the missing
> z-statistics.
>
> However, the coefficients do not provide any clear indication of a scaling
> problem.  Instead, if we accept the given solution point, the output
> indicates that there is very strong evidence against the presence of an
> inefficiency term in the model.  This raises the possibility that the
> problems with numerically identifying the parameters of interest may be due
> to model misspecification.
>
> Finally, Erik asked how is it possible that two packages could produce very
> different Z-statistics when the parameter estimates are very similar.  It
> might be that the different packages are using different estimators of the
> variance-covariance matrix.  By default, -frontier- in Stata uses the
> inverse of the average of the Hessian at the point of convergence.  It could
> be the other package is using another estimator, such as the inverse of the
> average outer product of the gradient (OPG) estimator.  (See Wooldridge
> (2002) chapter 13 for a discussion of the different estimators.)
>
> --David
>   [email protected]
>
>
> References
> ----------
>
> David M. Drukker and Vince Wiggins. 2004. "Verifying the solution from a
> Nonlinear Solver: A Case Study: Comment".  American Economic Review,
> Forthcoming.
>
> Jeffry M. Wooldridge. 2002. Econometric Analysis of Cross Section and Panel
> Data.  Cambridge, Mass: MIT Press.
>
> *
> *   For searches and help try:
> *   http://www.stata.com/support/faqs/res/findit.html
> *   http://www.stata.com/support/statalist/faq
> *   http://www.ats.ucla.edu/stat/stata/

*
*   For searches and help try:
*   http://www.stata.com/support/faqs/res/findit.html
*   http://www.stata.com/support/statalist/faq
*   http://www.ats.ucla.edu/stat/stata/



© Copyright 1996–2024 StataCorp LLC   |   Terms of use   |   Privacy   |   Contact us   |   What's new   |   Site index