Announcement

Collapse
No announcement yet.
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • Coefficient, SE and Residuals are same but not the predicted yhat

    Hi,

    I have noticed that when I run the following, they produce exactly similar results for coefficients, SE and residuals. However, their predicted yhats are not similar and this is due to different constents.

    My question is
    If I need to use predicted yhat, not the residuals, which model will I use? And how will I know that whatever I am choosing is the correct one for yhat?

    sysuse auto, clear
    xtset rep


    regress price mpg weight length i.rep i.trunk
    predict ccc1
    areg price mpg weight length i.trunk, absorb(rep)
    predict ccc
    reghdfe price mpg weight length, absorb (rep trunk)
    predict ccc2



    regress price mpg weight length i.rep i.trunk
    predict bbb1, residuals
    areg price mpg weight length i.trunk, absorb(rep)
    predict bbb, residuals
    reghdfe price mpg weight length, absorb (rep trunk) resid

  • #2
    If the residuals are all the same, then compute the predicted y as y minus residual. This is by definition.

    Comment


    • #3
      Raja, you are asking a very good question here, and I am afraid, the problem goes beyond the constant.

      In fixed effects models there is no constant, and whenever the command/software we use reports a constant, this constant is a fabrication of the programmer who programmed the command. Obviously different programmers need not fabricate the same fabrication. If the constant were the only problem, it would not affect covariances. But it does

      Code:
      . sysuse auto, clear
      (1978 Automobile Data)
      
      . qui regress price mpg weight length i.rep i.trunk
      
      . predict ccc1
      (option xb assumed; fitted values)
      (5 missing values generated)
      
      . qui areg price mpg weight length i.trunk, absorb(rep)
      
      . predict ccc
      (option xb assumed; fitted values)
      
      . qui reghdfe price mpg weight length, absorb (rep trunk)
      
      . predict ccc2
      (option xb assumed; fitted values)
      
      . correlate ccc1 ccc ccc2
      (obs=69)
      
                   |     ccc1      ccc     ccc2
      -------------+---------------------------
              ccc1 |   1.0000
               ccc |   0.9367   1.0000
              ccc2 |   0.7782   0.8670   1.0000
      the different predicted values should have been perfectly correlated, that is with a correlation of 1, but they are not.

      I am afraid that we need to think carefully what every command does when it predicts. I guess that when we absorb variables, they are not in the prediction equation at all.





      Comment


      • #4
        The output of help areg postestimation and help reghdfe suggest suitable adjustments that include the fixed effects in the predictions.
        Code:
        sysuse auto, clear
        regress price mpg weight length i.rep78 i.trunk
        predict ccc1, xb
        areg price mpg weight length i.trunk, absorb(rep78)
        predict ccc, xbd
        reghdfe price mpg weight length, absorb (rep78 trunk) resid
        predict ccc2, xbd
        pwcorr ccc1 ccc ccc2, obs
        Code:
        . pwcorr ccc1 ccc ccc2, obs
        
                     |     ccc1      ccc     ccc2
        -------------+---------------------------
                ccc1 |   1.0000 
                     |       69
                     |
                 ccc |   1.0000   1.0000 
                     |       69       69
                     |
                ccc2 |   1.0000   1.0000   1.0000 
                     |       64       64       64
                     |
        We note that predict after reghdfe includes predictions for 5 fewer observations than after reg and areg, consistent with the following output from reghdfe.
        Code:
        . reghdfe price mpg weight length, absorb (rep78 trunk) resid
        (dropped 5 singleton observations)

        Comment


        • #5
          Thank you very much William for suggesting an excellent solution to the problem.
          Thank you Joro and Andrew for the nice discussions.

          Comment

          Working...
          X