Numeric Overflow Error Message in Clogit

[Lamar Pierce]

Hi folks. I'm attempting to run a conditional (firm) fixed effects model in Stata 13.0, but keep getting the following error message:

"4733 (group size) take 292 (# positives) combinations results in numeric overflow; computations cannot proceed."

Can anyone tell me what this exactly means? My code is as follows (with varnames blinded for legal reasons):

clogit depvar indvar i.year `controls', group(firm) cluster(firm)

I get the same response using xtlogit

FYI: I have 1500 firm groups and approximately 1.6 million total observations.

Thanks,

Lamar

[William Lisowski]

Welcome to Statalist, Lamar.

This is not good news. Stata is telling you that one of your groups has 4,733 members with 292 positives among that group, and that leads Stata to an attempt to calculate the binomial coefficient



which Wolfram Alpha tells us is



or approximately 2.812 × 10⁴⁷⁴ which exceeds the limit for the largest number representable in double precision.

I'd say your problem is not solvable, at least in Stata. Since most software (Wolfram Alpha's engine is an exception, apparently) relies on the numerical functions engineered into the CPU, like double precision arithmetic, I would expect this to be a problem for most statistical software, unless the package has a different approach to maximization of the likelihood function.

I note that the documentation suggests that if the minimum, across all groups, of the number of successes and the number of failures exceeds 100, "patience may be required". To me that suggests groups larger than 200 will lead to ones patience being strained.

What I would hope is that someone else will comment on other possible approaches to this interesting, if gigantic, problem.

[William Lisowski]

In the post above, the two images no longer appear as they did when I posted.

The first of them is

and the second is

[Lamar Pierce]

Thanks William. I really appreciate your response. This is exactly what I was looking for. My alternative is using linear probability models with block bootstrapping, which although not ideal, approximates well enough. This indeed does not seem solvable, so I'll use the LPM.