[下载][推荐][讨论]Stata Questions and Answers

6960

收藏 2006-04-14

Dear list -members,

Please ignore it if you have read it before.

I'm trying to use logistic regression models to analyze the association
between SES and physical activity levels. My dependent variable is physical
activity level, which are grouped into three levels: a. regularly (ref), b.
occasionally, and infrequently. My questions are:
1. Can I conduct two separated logistic regression models to examine the
impact of SES on physical activity levels
a. DV (regularly vs occasionally)
b. DV (regularly vs infrequently)
or I have to run logistic regression with physical activity levels as
ordinal response variables?
2. if using two separated models is acceptable, is there anything missing in
comparing to using logistic regression with ordinal response variables?

3. what is the stata codes for this type analysis?

Thanks in advance for your help!

Jason Liu

扫码加我拉你入群

请注明：姓名-公司-职位

以便审核进群资格，未注明则拒绝

全部回复

Trevor

2006-4-14 22:20:00

You most likely want the Stata routines -ologit- or -oprobit-. Other
routines that might be appropriate include mlogit (which makes no
ordinality assumption), slogit, oglm, gologit2 or goprobit. To get a
better rundown on your alternatives, see the excellent Long and Freese book:

http://www.stata.com/bookstore/regmodcdvs.html

扫码加我拉你入群

请注明：姓名-公司-职位

以便审核进群资格，未注明则拒绝

Trevor

2006-4-14 22:22:00

Dear Maarten and Nick,

The translog described in my email does not estimate Beta21, Beta31 and
Beta32. The reason is because when one estimates the translog,, LnX1.LnX2 is
the same as Ln.X2.LnX1, similarly for LnX2.LnX3=LnX3.LnX2 etc.. These cross
products are not viewed as different from each other and hence only one of
the pair is estimated.

But the homogeneity test requires equality between Beta(12)=Beta(21) etc in
addition to the others..

I am new with this test for homogeneity and am hoping that I have got it
correct.

Regards,

Gauri

扫码加我拉你入群

请注明：姓名-公司-职位

以便审核进群资格，未注明则拒绝

Trevor

2006-4-14 22:23:00

以下是引用Trevor在2006-4-14 22:22:00的发言：
Dear Maarten and Nick,

The translog described in my email does not estimate Beta21, Beta31 and
Beta32. The reason is because when one estimates the translog,, LnX1.LnX2 is
the same as Ln.X2.LnX1, similarly for LnX2.LnX3=LnX3.LnX2 etc.. These cross
products are not viewed as different from each other and hence only one of
the pair is estimated.

But the homogeneity test requires equality between Beta(12)=Beta(21) etc in
addition to the others..

I am new with this test for homogeneity and am hoping that I have got it
correct.

Regards,

Gauri

If I understand you correctly, you have already imposed \beta_{ij} =\beta_{ji} -- that is, symmetry -- in your estimation. Hence, you cannot test your "fourth" restriction, as it holds by assumption. Hope that helps.

扫码加我拉你入群

请注明：姓名-公司-职位

以便审核进群资格，未注明则拒绝

Trevor

2006-4-14 22:35:00

I would like to run an F test using multiple restrictions on a translog
production function with three inputs. This forms a test for homegeneity
using the famous F test.

The restrictions that must be jointly imposed are:

1. Beta11+Beta12+Beta13=0
2. Beta21+Beta22+beta23=0
3.
Beta31+Beta32+Beta33=0http://by112fd.bay112.hotmail.msn.com/cgi-bin/compose?&curmbox=00000000%2d0000%2d0000%2d0000%2d000000000001&a=8e97f2d6d33d18578baf68a0a3ed4538f9bf87ce76a05b31a9e3bf145a925032#
Send
4. Beta12=Beta21; Beta13=Beta31, Beta23=Beta32

Any one have a clue on how to perform this?

Thank you,

Gauri Khanna
Graduate Institute of International Studies
University of Geneva

扫码加我拉你入群

请注明：姓名-公司-职位

以便审核进群资格，未注明则拒绝

Trevor

2006-4-14 22:37:00

以下是引用Trevor在2006-4-14 22:35:00的发言：
I would like to run an F test using multiple restrictions on a translog
production function with three inputs. This forms a test for homegeneity
using the famous F test.

The restrictions that must be jointly imposed are:

1. Beta11+Beta12+Beta13=0
2. Beta21+Beta22+beta23=0
3.
Beta31+Beta32+Beta33=0http://by112fd.bay112.hotmail.msn.com/cgi-bin/compose?&curmbox=00000000%2d0000%2d0000%2d0000%2d000000000001&a=8e97f2d6d33d18578baf68a0a3ed4538f9bf87ce76a05b31a9e3bf145a925032#
Send
4. Beta12=Beta21; Beta13=Beta31, Beta23=Beta32

Any one have a clue on how to perform this?

Thank you,

Gauri Khanna
Graduate Institute of International Studies
University of Geneva

Gauri Khanna:
If all parameters are estimated with one command than, this looks like job for the -test- command with the accum option.
HTH,
Maarten

-----------------------------------------
Maarten L. Buis
Department of Social Research Methodology
Vrije Universiteit Amsterdam
Boelelaan 1081
1081 HV Amsterdam
The Netherlands

扫码加我拉你入群

请注明：姓名-公司-职位

以便审核进群资格，未注明则拒绝

点击查看更多内容…

Trevor

2006-4-14 23:27:00

Thanks for the explanation. So, if I understand this,
the parameters are, or are forced to be, one and the same.

In that case, I can't see that you have a testable hypothesis,
or even a hypothesis. What you have ensured as a consequence
of your estimation is not an economic conjecture that needs to
be checked.

I'm reminded of a conversation I had in which I mentioned
that students from my university play ball games with
students from other universities on Wednesday. "Oh",
said the other person, from another university, "what
a coincidence, so too do students from my place". But
it wasn't a coincidence at all: it is all deliberate.
If Durham play Glasgow on Wednesdays, it follows ineluctably
that Glasgow play Durham on Wednesdays.

Nick
n.j.cox@durham.ac.uk

Gauri Khanna

扫码加我拉你入群

请注明：姓名-公司-职位

以便审核进群资格，未注明则拒绝

Trevor

2006-4-14 23:28:00

Dear Maarten and Nick,

Thank you again for your replies. Yes, I think I will drop it because there
is no conjecture involved and it does hold by definition. It's just strange
to see it in the test..

Also, ball games and homogeneity now go together!!

Regards,

Gauri

Doesn't that equality hold by definition? In that case there is no need to
test
it.

-----------------------------------------
Maarten L. Buis
Department of Social Research Methodology
Vrije Universiteit Amsterdam
Boelelaan 1081
1081 HV Amsterdam
The Netherlands

扫码加我拉你入群

请注明：姓名-公司-职位

以便审核进群资格，未注明则拒绝

Trevor

2006-4-14 23:29:00

Dear Stata-listers

I have a minor issue with the way STATA is rounding, for example a
variable to one decimal place.

I used the command

gen x=round(y, 0.1)

Comparing the two variables, I noticed the that when:

x= y=

8.750 8.7
5.752 5.8
23.256 23.3

Is there a way I can modify the function to round "x"=8.750 to be 8.8

Or should I put together my own code to get the rounding I want.

Many thanks in advance...

Amani

扫码加我拉你入群

请注明：姓名-公司-职位

以便审核进群资格，未注明则拒绝

Trevor

2006-4-14 23:30:00

Amani:

Stata 8.2 doesn't show this behaviour:

. input x

x
1. 8.750
2. 5.752
3. 23.256
4. end

. gen y = round(x, 0.1)

. list

+---------------+
| x y |
|---------------|
1. | 8.75 8.8 |
2. | 5.752 5.8 |
3. | 23.256 23.3 |
+---------------+

Maybe 8.750 in your data is actually 8.7499?

HTH,
Maarten

扫码加我拉你入群

请注明：姓名-公司-职位

以便审核进群资格，未注明则拒绝

Trevor

2006-4-14 23:31:00

Thanks for your reply Maarten, the values of x are exact ones and that
happens whenever you have "50" after the decimal you are cutting, for
example 0.*50, for the one decimal place, 0.**50 for the two decimal
place...etc.

Thanks for you help in advance.

Amani

扫码加我拉你入群

请注明：姓名-公司-职位

以便审核进群资格，未注明则拒绝

Trevor

2006-4-14 23:32:00

Another reason for not trusting your example
is that you claim to show us the results of

gen x = round(y, 0.1)

but in your output it is y that is rounded
and x that is coarse. So, evidently you changed
something before showing us your results.

Nick
n.j.cox@durham.ac.uk

Siyam, Amani

扫码加我拉你入群

请注明：姓名-公司-职位

以便审核进群资格，未注明则拒绝

Trevor

2006-4-14 23:33:00

Sorry,It is my mistake,

the command line should read
gen y=round(x, 0.1)

y is what I got after that.

Thanks again.

Amani

扫码加我拉你入群

请注明：姓名-公司-职位

以便审核进群资格，未注明则拒绝

Trevor

2006-4-14 23:34:00

Amani:

My example shows that it doesn't happen whenever you have 50 after the decimal point. My best guess is there are more decimals in your data than are displayed, leading you to believe that 8.750 is "exact". Try change the format and look at the variable again, like the example below:
format x %23.18f
list x in 1/10

HTH,
Maarten

扫码加我拉你入群

请注明：姓名-公司-职位

以便审核进群资格，未注明则拒绝

Trevor

2006-4-14 23:36:00

I can't speak about STATA. In Stata, which behaves
similarly in this instance, you can get rounding up
by using -ceil()-.

But note that you will find it difficult to avoid
small (apparent) anomalies whatever you do.

This because, in general, multiples of 0.1 cannot
be held exactly in binary, as explained many, many
times on this list.

Suppose I have 8.75 (meaning, precisely, 8 + 3/4).

Stata can hold that, _exactly_. In decimal,

. di %23.18f 8.750
8.750000000000000000

or, more to the point, in hexadecimal,

. di %21x 8.750
+1.1800000000000X+003

If I round that, Stata starts to struggle:

. di %21x round(8.750, 0.1)
+1.199999999999aX+003

. di %23.18f round(8.75,0.1)
8.800000000000000700

This raises the question of what, exactly, is
the number you are showing us which is (which
is represented as!) 8.750. Your number is,
I surmise, not exactly 8.750, as if it were
it would round to 8.8.

That said, there is no way you can avoid this kind of
problem by writing your own program, unless
you also construct a decimal-based computer.

Nick
n.j.cox@durham.ac.uk

Siyam, Amani

> I have a minor issue with the way STATA is rounding, for example a
> variable to one decimal place.
>
> I used the command
>
> gen x=round(y, 0.1)
>
> Comparing the two variables, I noticed the that when:
>
> x= y=
>
> 8.750 8.7
> 5.752 5.8
> 23.256 23.3
>
> Is there a way I can modify the function to round "x"=8.750 to be 8.8
>
> Or should I put together my own code to get the rounding I want.

*
* 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/

扫码加我拉你入群

请注明：姓名-公司-职位

以便审核进群资格，未注明则拒绝

Trevor

2006-4-14 23:37:00

Amani--

All of what Nick says is true, but the claim that "there is no way you

can avoid this kind of problem by writing your own program, unless you

also construct a decimal-based computer" is overreaching a bit. It's
true that the general problem of numerical precision is unavoidable,
but the specific problem you want to address is not. If you want to
force the incorrect behavior you seem to want (rounding 8.64999999999
to 8.7) there is a way to do it. If you are representing your numbers
as having 2 digits after the decimal point, and you believe that such
a representation is true and the more accurate binary representation
is not, then you can force the rounding you want by treating your
representation as a string--but you could be introducing error in any
setting where your homemade rounding method does not match the
binary-based rounding done by your computer.

. clear
. set obs 100
. gen obs=_n/100
. gen real=round(obs, .1)
. gen silly=round(real(string(obs*100, "%4.0f")),10)/100
. li in 64/66

+--------------------+
| obs real silly |
|--------------------|
64. | .64 .6 .6 |
65. | .65 .6 .7 |
66. | .66 .7 .7 |
+--------------------+

Your original post raises the question of how you got the numerical
8.75 so that you know the decimal representation is exact, but the
computer doesn't (did you do a whole series of calculations that
should result in exactly 35/4 but instead results in a close, but not
close enough, approximation?) If so, you can turn your calculation on
integers like X into calculations using integers by using an
appropriate factor, such as 4X or 40X or 100X, and get the "right"
answer (but the appropriate factor to apply before and after the
intermediate calculations to preserve accuracy will depend on what the
intermediate calculations are). Bear in mind always that

. di round(35/4,.1)
8.8

gives you the answer you seem to want, and you should be able to get
there from here.

--Austin

- Show quoted text -

*
* 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/

扫码加我拉你入群

请注明：姓名-公司-职位

以便审核进群资格，未注明则拒绝

Trevor

2006-4-14 23:39:00

I'm (basically) comparing a multivariate Probit (using the mvprobit
command) with a method employing inverse distributions and the sureg
command for their subsequent multivariate normal distribution. Even
using normal inversesof univariate probit probabilities however my sureg
log-likelihoods are a good deal higher/less negative than the mvprobit
ones, which is unexpected. I'm wondering whether the sureg perhaps uses
concentrated log-likelihoods. The manual doesn't cover this, but does
anybody out there have any information, or a similar experience?

Casey Quinn
Centre for Health Economics
University of York

扫码加我拉你入群

请注明：姓名-公司-职位

以便审核进群资格，未注明则拒绝

Trevor

2006-4-14 23:41:00

I have the following estimation problem: I am estimating a probit of y1
on y2 x1 with instrumental variables z, where y2 is one endogenous
variable, x1 is of dimension K, and z is of dimension L, L>1. I apply a
maximum likelihood optimization as described in
Wooldridge (2002), p. 477f.

I undertake a Rivers-Vuong endogeneity test as described in Wooldridge
(2002), p. 474.

Question: does there exist a test on overidentifying restrictions that
tests the validity of instruments in this case? Or does anybody know
whether the ivreg2 command together with overid is applicable for probit
estimation with binary endogenous variables, too?

扫码加我拉你入群

请注明：姓名-公司-职位

以便审核进群资格，未注明则拒绝

Trevor

2006-4-14 23:43:00

I'm currently writing a research proposal for an analysis of a simple
panel dataset with two data points. That is, there's an entry survey
and an exit survey. This is the first time I've analyzed this sort of
data, and wonder if you folks have any thoughts about what issues might
come up other than the obvious. There's considerable variation in the
dependent variable with individuals as the unit of analysis (with
approximately 10,000 cases), but the primary independent variable of
interest is "contextual" or "environmental." That is, it will be
aggregated in a way such that about every 100 to 1,000 individuals will
have same value for the variable. Most of the other control variables
won't be aggregated.

So, does the fact that the independent variable is aggregated raise
methodological issues that undermine the benefits of panel data? I
imagine that a lot of panel studies must account for these environment
variables, but what are the chief pitfalls and how does one adjust for
them? Would it be advisable or necessary to conduct a separate analysis
at a higher level of aggregation and compare the results? Is there a
good reference for this kind of analysis that wouldn't take me a
semester to read and digest?
*

扫码加我拉你入群

请注明：姓名-公司-职位

以便审核进群资格，未注明则拒绝

扫码加我 拉你入群

扫码加我 拉你入群

扫码加我 拉你入群

扫码加我 拉你入群

扫码加我 拉你入群

扫码加我 拉你入群

扫码加我 拉你入群

扫码加我 拉你入群

扫码加我 拉你入群

扫码加我 拉你入群

扫码加我 拉你入群

扫码加我 拉你入群

扫码加我 拉你入群

扫码加我 拉你入群

扫码加我 拉你入群

扫码加我 拉你入群

扫码加我 拉你入群

扫码加我 拉你入群

扫码加我 拉你入群

分享

扫码加好友，拉您进群

扫码加我拉你入群

扫码加我拉你入群

扫码加我拉你入群

扫码加我拉你入群

扫码加我拉你入群

扫码加我拉你入群

扫码加我拉你入群

扫码加我拉你入群

扫码加我拉你入群

扫码加我拉你入群

扫码加我拉你入群

扫码加我拉你入群

扫码加我拉你入群

扫码加我拉你入群

扫码加我拉你入群

扫码加我拉你入群

扫码加我拉你入群

扫码加我拉你入群

扫码加我拉你入群