[Date Prev][Date Next][Thread Prev][Thread Next][Date index][Thread index]

From |
jpitblado@stata.com (Jeff Pitblado, StataCorp LP) |

To |
statalist@hsphsun2.harvard.edu |

Subject |
Re: st: Interesting (?) -ml- question |

Date |
Wed, 08 Sep 2004 09:37:07 -0500 |

Mark Schaffer <M.E.Schaffer@hw.ac.uk> asks a follow-up question regarding -ml- and what appear to be multiple offset variables: > Thanks for the rapid feedback. I hope this doesn't look like I'm biting a > hand that fed me, but can I point out what looks like (to an ML neophyte, > at any rate) a drawback of your recommended approach? > The issue arises if I want to write a general ML estimator of this form - > say, something like LIML (which can be solved using eigenvales, but you get > the idea). The user specifies the dependent variable, the regressors, and > the additional variables involved in the likelihood (in the LIML case, > these are just the instruments). There could be any number of regressors > and instruments. > Won't code that handles an arbitrary number of instruments in the style > you've described get messy? There could be dozens or even hundreds of > additional equations, and each gets its own constraint. Yes, it could get messy. For the associated general solution, you would have to build some loops in your eclass command the calls -ml- and your likelihood evaluator that -ml- calls; although, I wouldn't call all loops messy. The args line isn't that hard to build either, it will also take a small loop. > What would the -args- line look like in the program that calculates the > value of the likelihood? Here is an outline of a method -lf- likelihood evaluator: program myll version 8.2 gettoken lnf 0 : 0 local k_xeqns : word count `0' forvalues i = 1/`k_xeqns' { gettoken x`i' 0 : 0 } // now you can reference `x`i'' in a subsequent loop that // evaluates your likelihood ... end > Would the numerical calculations be affected if I work with really big > matrices? That would depend entirely on the data and the form of the likelihood. > This is why I thought my option 1 below (put the names of the instruments > in a global macro) would probably be the best choice, even though, from the > point of view of programming aesthetics, it's not very elegant. For a one-time data analysis project, your solution works fine. I try not to use globals when there are other solutions available to me; especially when I will be coming back to the problem again sometime in the near future. --Jeff jpitblado@stata.com * * 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/

- Prev by Date:
**st: Scheme error message** - Next by Date:
**st: Stata 7 Documentation** - Previous by thread:
**Re: st: Interesting (?) -ml- question** - Next by thread:
**st: Graph with two x-ases** - Index(es):

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