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

RE: st: problem with MLE

From   "Verkuilen, Jay" <[email protected]>
To   <[email protected]>
Subject   RE: st: problem with MLE
Date   Mon, 3 Dec 2007 13:06:19 -0500

Maarten Buis wrote:

>>I can't spot the problem, but I can tell you that a useful debugging
strategy is to start with a much smaller program and gradually build it
to the full model that is desired. Substantively such smaller models may
be completely unacceptable within your discipline, but don't worry about
that, it is just a step in getting the mechanics to work. Sometimes such
smaller models happen to coincide with models that are already
implemented in Stata, so you can use that as a check of whether you
start from the right point.<<

I think Maarten's advice is right on. Build your models sequentially
starting from simple but probably wrong ones that are constrained
versions of the one you want to estimated. 

The numerical methods used in ML estimation are all "locally convergent"
which means that unless they are started sufficiently close to the right
answer (or unless certain global optimality conditions are met, which is
not true generally), they can do all sorts of bad things: diverge (the
least bad because you know you don't have an answer), converge to a
local optimum that looks like a good solution (bad!), throw an improper
solution (you'll see standard errors blow up, usually), etc. Sometimes
you have to play with the numerical functions, e.g., switch from a
quasi-Newton to a full Newton or use a different type of numerical
integration, to make progress. 

In fact, if you look at the way Stata initializes complex models like,
say, ZINB (zero-inflated negative binomial), it does exactly this, first
fitting the Poisson model, then fitting the NB model with no regressors,
etc. This adds estimation time but always gives the next model better
starting values from which to work. 

I've fit probably hundreds of mixed ML models in various packages
(Stata, SAS, R, winBUGS, homegrown, etc.). All have peculiarities about
how they handle the initialization process, how robust they are to
problems, what their error codes *actually* mean, which program bugs
haven't been fixed yet. The experience you gain fitting the simpler
models that don't entirely line up with your problem is invaluable for
finding out what is likely to go wrong when you move up to the next
level. It's not a question of if, but when, things go wrong.... 

J. Verkuilen
Assistant Professor of Educational Psychology
City University of New York-Graduate Center
365 Fifth Ave.
New York, NY 10016
Email: [email protected]
Office: (212) 817-8286 
FAX: (212) 817-1516
Cell: (217) 390-4609

*   For searches and help try:

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