Notice: On April 23, 2014, Statalist moved from an email list to a forum, based at statalist.org.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

From |
John Litfiba <[email protected]> |

To |
[email protected] |

Subject |
Re: st: too good to be true : lr test in mlogit? |

Date |
Mon, 16 May 2011 16:09:01 +0200 |

Hello Joerg, Thank you for your answer My data is organized as follows (simplified) id1 year1 age type outcome id1 year1 age type outcome id1 year2 age type outcome id1 year3 age type outcome id2 year4 age type outcome id3 year2 age type outcome id3 year5 age type outcome For example, lets say the outcome is a trading decision (Buy or Sell) and I want to estimate the effect of age and type (Good or Bad) on that decision. Some individuals may trade just once and others may trade several times per year. The total number of trade thus vary per individuals (in the above example individual 1 has made 4 trade, while individual 1 juste one) The outcome is the same for each individuals (Buy or Sell) Type vary with the observation (today I can be BAD and tomorrow GOOD) but it is likely that type is correlated within clusters of id... Age vary of course with year Applying a mlogit with "mlogit outcome age type" , cluster(id) works fine but I cannot run xtlogit (I write before that the command XTSET id in order to make stata understand the panel dataset) What do you think ? Best Regards, On 16 May 2011 15:38, Joerg Luedicke <[email protected]> wrote: > > Hi John, > > Could you explain a little bit what your data looks like? It looks as > if you have observations nested within subjects, correct? What are > those observations and what are your subjects then? I have a slight > hunch that you want to run a 2-level model (Level 2 being whatever > your variable "id" is referring to, and Level 1 the however structured > observations within "id") and that you are trying to predict an > outcome on Level 2 with Level 1 predictors or something like that. > > J. > > On Mon, May 16, 2011 at 7:11 AM, John Litfiba <[email protected]> wrote: > > Dear Maarten yes the variable is correctly coded with 1 and 0 (you > > probably miss my previous mail ;-) ) > > Thank you for the advice, I will contact the tech support to see whats > > wrong here > > > > Best Regards, > > > > > > On 16 May 2011 12:30, Maarten Buis <[email protected]> wrote: > >> On Mon, May 16, 2011 at 12:02 PM, John Litfiba <[email protected]> wrote: > >>> Well, when I run a xtlogit (I first type xtset id, where id is the > >>> unique id for each of my individual in my database) with on year of > >>> data (1million) observations I get the message > >>> > >>> Yvar is categorical (Yes=1, No=0) and Xvar is also categorical > >>> (type1=1, type2=2) > >> > >> I would recode Xvar to such that type1 = 0 and type2 = 1: > >> gen byte type2 = Xvar - 1 > >> > >> Remember that with fixed or random effects models you are making an > >> additional model for the group specific constants. It often helps when > >> these group specific constant refer to groups that actually occur in > >> the data. > >> > >> the logic of calling this variable type2 rather than Xvar is that the > >> value 1 is often associated with "true" and 0 with "false", so I think > >> of a variable named type2 as posing a question to each observation > >> "are you type2?", the answer being either true (1) or false (0). > >> > >> If recoding your explanatory variable does not work I would contact > >> Stata's techsupport, as these results suggest that there is something > >> logically wrong with the model you are trying to estimate, so ad-hoc > >> solutions like sampling from your data are not advisable until you > >> understand where the problem comes from. For how to contact Stata's > >> techsupport, see: http://www.stata.com/support/tech-support/ > >> > >> Hope this helps, > >> Maarten > >> > >> -------------------------- > >> Maarten L. Buis > >> Institut fuer Soziologie > >> Universitaet Tuebingen > >> Wilhelmstrasse 36 > >> 72074 Tuebingen > >> Germany > >> > >> > >> http://www.maartenbuis.nl > >> -------------------------- > >> * > >> * For searches and help try: > >> * http://www.stata.com/help.cgi?search > >> * http://www.stata.com/support/statalist/faq > >> * http://www.ats.ucla.edu/stat/stata/ > >> > > > > * > > * For searches and help try: > > * http://www.stata.com/help.cgi?search > > * http://www.stata.com/support/statalist/faq > > * http://www.ats.ucla.edu/stat/stata/ > > > > * > * For searches and help try: > * http://www.stata.com/help.cgi?search > * http://www.stata.com/support/statalist/faq > * http://www.ats.ucla.edu/stat/stata/ * * For searches and help try: * http://www.stata.com/help.cgi?search * http://www.stata.com/support/statalist/faq * http://www.ats.ucla.edu/stat/stata/

**References**:**st: too good to be true : lr test in mlogit?***From:*John Litfiba <[email protected]>

**Re: st: too good to be true : lr test in mlogit?***From:*Maarten Buis <[email protected]>

**Re: st: too good to be true : lr test in mlogit?***From:*John Litfiba <[email protected]>

**Re: st: too good to be true : lr test in mlogit?***From:*Maarten Buis <[email protected]>

**Re: st: too good to be true : lr test in mlogit?***From:*Joerg Luedicke <[email protected]>

**Re: st: too good to be true : lr test in mlogit?***From:*John Litfiba <[email protected]>

**Re: st: too good to be true : lr test in mlogit?***From:*Maarten Buis <[email protected]>

**Re: st: too good to be true : lr test in mlogit?***From:*John Litfiba <[email protected]>

**Re: st: too good to be true : lr test in mlogit?***From:*Maarten Buis <[email protected]>

**Re: st: too good to be true : lr test in mlogit?***From:*John Litfiba <[email protected]>

**Re: st: too good to be true : lr test in mlogit?***From:*Joerg Luedicke <[email protected]>

- Prev by Date:
**Re: st: rreg v.s regress** - Next by Date:
**st: check if a macro contains a value** - Previous by thread:
**Re: st: too good to be true : lr test in mlogit?** - Next by thread:
**st: export table of summary statistics to excel** - Index(es):