Statalist


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

st: new ml evaluator type needed?/cmp upgrade


From   "David Roodman ([email protected])" <[email protected]>
To   <[email protected]>
Subject   st: new ml evaluator type needed?/cmp upgrade
Date   Mon, 14 Jul 2008 12:17:39 -0400

I have just posted another upgrade to -cmp-. See
http://stata.com/statalist/archive/2008-07/msg00231.html
for more on the program.

"ssc install cmp, replace" installs the progam.

The new version is significantly faster in many situations. I no longer
so readily recommend relying on tech(dfp) because -cmp- now often works
quite well with -ml-'s default Newton-Raphson search method. Sometimes
alternating between DFP and NR is the best, such as with tech(dfp nr).
NR seems best where the likelihood is concave, and DFP when it isn't.

The main internal change is that -cmp- is now by default a "pseudo-d2"
evaluator. It computes scores analytically, like a d1 evaluator, and
then it computes the Hessian numerically, based on those analytical
scores. The advantage in this is that it can compute the Hessian faster
than -ml- does when working with d1 evaluators, by taking advantage of
the linear form of -cmp- models. This means it only needs to compute the
likelihood twice for each *equation* (at +h and -h relative to the
current solution, where h is a small number) rather than twice for each
*parameter*.

This leads to a larger question in my mind about -ml-: is there a
missing evaluator type? With -ml-, d1-type evaluators save time compared
to d0 by computing scores analytically. Meanwhile, -lf- evaluators save
time compared to d0 by assuming the likelihood has linear form: in
computing scores in lf mode, -ml- only needs to compute the likelihood
once for each equation instead of once for each parameter (and ditto
quadratically for the Hessian). So for linear-form likelihoods for which
one can compute scores analytically, one faces a trade-off: lf and d1
save time in different ways, so sometimes one will be better and
sometimes the other.

It struck me that this trade-off may be theoretically unnecessary.
Perhaps -ml- should have a "lfd1" evaluator type that accepts
analytically computed scores *and* takes advantage of the linear form.



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