Note: This FAQ is for users of releases prior to Stata 6. It is not relevant for more recent versions.

Title | Conditional logit model and clogit | |

Author | William Sribney, StataCorp | |

Date | January 1999 |

It’s a “normal” message, but, in Stata 4.0 (or earlier), you may want to be concerned depending on your data.

Stata’s **
clogit** has always done **1:n_i** matching using the exact
conditional likelihood. But in version 4.0 and earlier, it used an
approximation to the likelihood for **m_i:n_i** matching when **m_i >
1**.

In Stata 5.0 and 6.0, **clogit** always uses the exact conditional
likelihood. So, it doesn’t matter what type of data you have; it
always gives appropriate estimates.

First, let me explain what I mean by **1:n_i** matching, etc. Let
**i** index the groups (called strata by **clogit** in versions 4.0
and earlier). **1:n_i** matching means that in the i-th group, there is
1 subject (i.e., observation) with a dependent variable **y = 1** and
there are **n_i** subjects with **y = 0**.

For **1:n_i** matching, version 4.0 **clogit** and versions 5.0 and
6.0 **clogit x** give EXACTLY the same answers.

“Multiple positive outcomes within groups encountered” means
there is at least one group j with **m_j:n_j** matching, where
**m_j** > 1; i.e., in the j-th group, there are 2 or more subjects with
**y = 1**. This general model is often called the conditional
fixed-effects logit model.

In version 4.0 and earlier, the approximation used for **m_j:n_j**
matching was only good when **m_j << n_ji** (as the Methods and
Formulas section discussed). For **m_j** approximately the same as
**n_j** (or bigger than), it is a terrible approximation.

In versions 5.0 and 6.0, **clogit** ALWAYS uses the exact conditional
likelihood, so there is no cause for concern when you see the
“multiple positive outcomes within strata
encountered”—except if you think you should have **1:n_i**
matched data, in which case you have an error in your dataset.

The new recursive algorithm was not implemented before version 5.0 because it was not well-known.

Often one will see in a text or review that **m_j:n_j** matching is
computationally impossible for anything but small **m_j**. But this is
only true if one uses an enumerative algorithm that steps through all
C(m_j+n_j, m_j) possibilities.

The recursive algorithm is proportional to **m_j** (actually it's the
minimum of **m_j** and **n_j**), so it gets slower as **m_j**
increases but not unduly.

The bottom line is we strongly recommend anyone doing
**m_j:n_j** matching upgrade to at the current version of Stata and use
**clogit**.