On 1/9/07, John Fulton <[email protected]> wrote:
> Richard Gates suggested modifying nlogitrum to remove a trap
Dear Richard,
Thank you very much.
Yes, thank you!
Does nlogitrum call the current version of nlogit, subject to the trap?
Or does nlogitrum have access to an older version of nlogit, somehow?
As Richard wrote, the code in -nlogitrum- is based on the Stata 7
release of -nlogit-. If you want to view the source code but are
afraid of changing something in the program by mistake, use the
command -viewsource-.
In other words, is there anything I would be giving up by going with
nlogitrum's version of nlogit?
I'm obviously thinking of "inside-Stata" stuff, like speed increases
since 7, for example, or something else that might not show up in the
nlogit version changelogs?
I can think of 3 things that you would be giving up: (1) the ml method
d1, (2) official Stata tech support, and (3) the overall quality and
scrutiny that comes with official Stata commands.
Hess wrote in the SJ 2-3 article on page 248 that -nlogitrum- uses the
ml method d0 whereas -nlogit- uses the ml method d1. Again, this can
be confirmed with -viewsource-. Method d1 is better, because it
produces the gradient in addition to the log-likelihood value; see the
manual for -ml-.
Because I could (at least in principle) use the Koppelman-and-Wen
constraint of equality of IV parameters to produce a RUM-consistent
estimation. [...]
Yes, as long as the official version of nested logit is inconsistent
with Random Utility Maximization (RUM) theory, the justification for
using the unofficial -nlogitrum- instead of the official -nlogit- is
to have a RUM-consistent estimation.
Anders
[email protected]
*
* 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/
