Stata The Stata listserver
[Date Prev][Date Next][Thread Prev][Thread Next][Date index][Thread index]

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

From (Jeff Pitblado, StataCorp LP)
Subject   Re: st: Interesting (?) -ml- question
Date   Wed, 08 Sep 2004 09:37:07 -0500

Mark Schaffer <> 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


> 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.

*   For searches and help try:

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