<p>I'm afraid the accepted answer is not precise enough, and can be deeply misleading. </p>

<p>This issue is formally called the <strong>Generated Regression problem</strong> which arises when we use "generated" regressors in a regression. This is a very common feature of estimations like Heckman Selection Model, where we use the predicted Inverse Mills Ratio from the selection equation in the structural equation. We need to divide the issue in two:</p>

<ul>
<li><p><strong>Consistency</strong>: there is usually no problem of consistency when using generated regressors in an estimation. A formal proof can be found in Wooldridge (2010), page 123.  </p></li>
<li><p><strong>Statistical inference</strong>: here there might be problems. <strong>Under the null</strong> that generated regressors are zero, then standard errors and all tests are valid (you might still need to correct for heteroscedasticity and serial correlation as usual, using robust standard errors). However, if the generated regressor is statistically significant, then the standard errors and in consequence any test are <strong>invalid</strong>. What you need is a correct estimation of the asymptotic variance. The formulas depend on each case (more information in Newey and McFadden [1994]). However, a general solution to calculate the consistent standard errors is to use <strong>bootstrapping</strong>. As an aside, for example, if you use Stata, just run your normal command with the following code before:</p>

<pre><code>bootstrap, reps(400) seed(10101): regres ...
</code></pre></li>
</ul>

<p><code>reps</code> is the number of repetitions and <code>seed</code> is for reproducibility. </p>

<p><strong>TL;DR</strong></p>

<p>If your generated regressor is <strong>statistically significant</strong> in your regression, then you need to estimate the standard errors using <strong>boostrapping</strong> because they are <strong>invalid</strong>. If they are insignificant, you are safe. </p>

CC BY-SA 3.0
2017-02-23T19:39:08.200Z
Two questions: 1. What is Wooldridge (2010)? 2. Should you not bootstrap the generation of regressors, too, to account for the "measurement error" due to using generated regressors in place of "real" ones? I do not see how simply bootstrapping the errors of the final model would address the problem of generated regressors.
Richard Hardy
CC BY-SA 4.0
2022-12-01T08:39:37.140Z
Yes, you should!
Papayapap
CC BY-SA 3.0
2016-08-11T14:02:28.130Z
2016-08-11T14:17:32.310Z
2016-08-11T14:17:32.310Z
luchonacho
<p>The answer from someone</p>

<p>Case 1: There is an estimation error in beta_hat. So Z should be really named Z_hat, which is different from the true Z defined as exp(beta_0). The estimation error translates into the error-in-variable problem in the second regression. The OLS estimator of mu will suffer from attenuation bias in finite samples. However, in large samples, when the variance of the estimation error in beta_hat goes to zero, the attenuation bias disappears. So you can run the regression as usual. </p>

<p>Case 2: Not a problem. Just run the regression as usual. </p>

<p>Case 3: No a problem, as long as you can estimate the k's precisely. That is, the numerical errors have to be very small. Otherwise, you will have the same problem as in Case 1. </p>

CC BY-SA 3.0
2016-08-10T08:39:17.437Z
2016-08-10T08:39:17.437Z
XJ.C
<p>luchonacho's answer is good to keep in mind but it doesn't mean you can't do what you are proposing, only that you should have a good reason for doing so. </p>

<p>Since you are only using your estimated variable in case 1 and case 2 I'm going to focus on those.</p>

<p>In both case 1 and case 2 you are estimating a simple linear regression with X as the regressor and y as the dependent variable. This implies that you believe X and Y are related in a strictly linear sense. So your beta hat is telling you the slope of the line between X and Y. </p>

<p>You then raise h to a power of beta hat. I assume h is another variable. Essentially this is just a transformation of h. You are raising every single value stored in h to a power of beta hat. </p>

<p>If that's what you want to do it seems to be a valid way to do it but I'm struggling to interpret what z would mean without knowing how your variables are related. </p>

<p>I'm also struggling to see why you need to do the transformation in the first place. With a few details on how the variables are related, or perhaps a link to the some of the literature your work is citing I might be able to be of more assistance. </p>

<p>As it stands right now, I would say that your regressions using the variable z are meaningless economically and have significant statistical issues as well. I strongly recommend taking a step back and thinking about your specifications again. </p>

CC BY-SA 3.0
2017-02-24T16:42:49.067Z
2017-02-24T16:42:49.067Z
Sean Lambert
<p>Can I use calculated data for regression analysis.</p>

<p>case 1: first run OLS $y = \alpha+\beta x$, and get $\hat\beta$, then calculate $z = h^\hat\beta$, at last run $m = \gamma + \mu z$.</p>

<p>case 2: follow the same settings as case 1, run $z = \zeta + \rho p$.</p>

<p>case 3: use matlab solve equation $k_i = \sum_j d_{ij} k_j$ for $k_i$, then run $w = \theta + \pi k$.</p>

<p>where $\alpha$,$\beta$,$\gamma$,$\mu$,$\zeta$,$\rho$,$\theta$,and $\pi$are coefficients, the other letters denote the variables.I have the variables y,x,h,m,p,$d_{ij}$,w. All the relationships between variables are from the models.</p>

<p>They are independent cases that I ran into.</p>

<p>I am going to estimate the coefficients $\mu$,$\rho$,and $\pi$.</p>

CC BY-SA 3.0
2016-08-05T16:15:26.207Z
Yes you can, but do you want someone to show you how to estimate these parameters?
london
CC BY-SA 3.0
2016-08-05T17:05:02.767Z
@london No. I just want to know the method I use to prepare the data for regression is right. I thought it should use those observable data rather than calculated data.
XJ.C
CC BY-SA 3.0
2016-08-05T17:53:41.423Z
In that case, you should explain the background to the problem.
london
CC BY-SA 3.0
2016-08-06T01:07:49.820Z
@london They are independent problems that I ran into
XJ.C
CC BY-SA 3.0
2016-08-06T19:35:55.263Z
Then, it is fine go ahead with what you described.
london
CC BY-SA 3.0
2016-08-10T06:53:15.207Z
OK, why do you want to estimate those parameters. What do they *mean*? It does not make sense to talk about estimating parameters without any context.
410 gone
CC BY-SA 3.0
2016-08-10T08:41:02.977Z
It is guided by the model.
XJ.C
<regression>
Can I use calculated data for regression
XJ.C
# Can I use calculated data for regression

(Asked by: username_0 on 2016-08-05)

Can I use calculated data for regression analysis.

case 1: first run OLS $y = \alpha+\beta x$, and get $\hat\beta$, then calculate $z = h^\hat\beta$, at last run $m = \gamma + \mu z$.

case 2: follow the same settings as case 1, run $z = \zeta + \rho p$.

case 3: use matlab solve equation $k\_i = \sum\_j d\_{ij} k\_j$ for $k\_i$, then run $w = \theta + \pi k$.

where $\alpha$,$\beta$,$\gamma$,$\mu$,$\zeta$,$\rho$,$\theta$,and $\pi$are coefficients, the other letters denote the variables.I have the variables y,x,h,m,p,$d\_{ij}$,w. All the relationships between variables are from the models.

They are independent cases that I ran into.

I am going to estimate the coefficients $\mu$,$\rho$,and $\pi$.

**Tags:** regression
> **Comments:**
> **username_1**: Yes you can, but do you want someone to show you how to estimate these parameters?  
> **username_0**: @london No. I just want to know the method I use to prepare the data for regression is right. I thought it should use those observable data rather than calculated data.  
> **username_1**: In that case, you should explain the background to the problem.  
> **username_0**: @london They are independent problems that I ran into  
> **username_1**: Then, it is fine go ahead with what you described.  
> **username_2**: OK, why do you want to estimate those parameters. What do they *mean*? It does not make sense to talk about estimating parameters without any context.  
> **username_0**: It is guided by the model.  

---

## 3 answers

### Answer by username_3 on 2016-08-11. Score: 2 | Accepted answer

I'm afraid the accepted answer is not precise enough, and can be deeply misleading. 
This issue is formally called the Generated Regression problem which arises when we use "generated" regressors in a regression. This is a very common feature of estimations like Heckman Selection Model, where we use the predicted Inverse Mills Ratio from the selection equation in the structural equation. We need to divide the issue in two:

Consistency: there is usually no problem of consistency when using generated regressors in an estimation. A formal proof can be found in Wooldridge (2010), page 123.  
Statistical inference: here there might be problems. Under the null that generated regressors are zero, then standard errors and all tests are valid (you might still need to correct for heteroscedasticity and serial correlation as usual, using robust standard errors). However, if the generated regressor is statistically significant, then the standard errors and in consequence any test are invalid. What you need is a correct estimation of the asymptotic variance. The formulas depend on each case (more information in Newey and McFadden [1994]). However, a general solution to calculate the consistent standard errors is to use bootstrapping. As an aside, for example, if you use Stata, just run your normal command with the following code before:
bootstrap, reps(400) seed(10101): regres ...


reps is the number of repetitions and seed is for reproducibility. 
TL;DR
If your generated regressor is statistically significant in your regression, then you need to estimate the standard errors using boostrapping because they are invalid. If they are insignificant, you are safe.

> **Comments:**
> **username_4**: Two questions: 1. What is Wooldridge (2010)? 2. Should you not bootstrap the generation of regressors, too, to account for the "measurement error" due to using generated regressors in place of "real" ones? I do not see how simply bootstrapping the errors of the final model would address the problem of generated regressors.  
> **username_5**: Yes, you should!  

---

### Answer by username_0 on 2016-08-10. Score: 1

The answer from someone

Case 1: There is an estimation error in beta\_hat. So Z should be really named Z\_hat, which is different from the true Z defined as exp(beta\_0). The estimation error translates into the error-in-variable problem in the second regression. The OLS estimator of mu will suffer from attenuation bias in finite samples. However, in large samples, when the variance of the estimation error in beta\_hat goes to zero, the attenuation bias disappears. So you can run the regression as usual.

Case 2: Not a problem. Just run the regression as usual.

Case 3: No a problem, as long as you can estimate the k's precisely. That is, the numerical errors have to be very small. Otherwise, you will have the same problem as in Case 1.


---

### Answer by username_6 on 2017-02-24. Score: 1

luchonacho's answer is good to keep in mind but it doesn't mean you can't do what you are proposing, only that you should have a good reason for doing so.

Since you are only using your estimated variable in case 1 and case 2 I'm going to focus on those.

In both case 1 and case 2 you are estimating a simple linear regression with X as the regressor and y as the dependent variable. This implies that you believe X and Y are related in a strictly linear sense. So your beta hat is telling you the slope of the line between X and Y.

You then raise h to a power of beta hat. I assume h is another variable. Essentially this is just a transformation of h. You are raising every single value stored in h to a power of beta hat.

If that's what you want to do it seems to be a valid way to do it but I'm struggling to interpret what z would mean without knowing how your variables are related.

I'm also struggling to see why you need to do the transformation in the first place. With a few details on how the variables are related, or perhaps a link to the some of the literature your work is citing I might be able to be of more assistance.

As it stands right now, I would say that your regressions using the variable z are meaningless economically and have significant statistical issues as well. I strongly recommend taking a step back and thinking about your specifications again.


---

