R help - Dec 2003 - chisq.test freezing on certain inputs

Hello everybody,

I'm running R 1.8.1 on both Linux and OS X compiled with gcc 3.2.2 and 
3.3, respectively.  The following call seems to freeze the interpreter 
on both systems:
 > chisq.test(matrix(c(233, 580104, 3776, 5786104), 2, 2), 
simulate.p.value=TRUE)

By freeze, I mean, the function call never returns (running > 10 hours 
so far), the process is unresponsive to SIGINT (but I call kill it with 
TERM), and the process still consumes cycles on the CPU.

Browsing through the code, it seems to be getting stuck on the C call 
to "chisqsim" .

Browse[1]>
debug: tmp <- .C("chisqsim", as.integer(nr), as.integer(nc), 
as.integer(sr),
     as.integer(sc), as.integer(n), as.integer(B), as.double(E),
     integer(nr * nc), double(n + 1), integer(nc), results = double(B),
     PACKAGE = "ctest")
Browse[1]>

Has anyone seen this, or know what may be causing it?

Thanks,
Jeff

On Thu, 11 Dec 2003, Jeffrey Chang wrote:
> Hello everybody,
>
> I'm running R 1.8.1 on both Linux and OS X compiled with gcc 3.2.2 and
> 3.3, respectively.  The following call seems to freeze the interpreter
> on both systems:
>  > chisq.test(matrix(c(233, 580104, 3776, 5786104), 2, 2),
> simulate.p.value=TRUE)
>
> By freeze, I mean, the function call never returns (running > 10 hours
> so far), the process is unresponsive to SIGINT (but I call kill it with
> TERM), and the process still consumes cycles on the CPU.
>
This is due to calling `exp' with a very small value leading to
a zero return value in rcont2 (src/appl/rcont.c) line 70:

            x = exp(fact[iap - 1] + fact[ib] + fact[ic] +
                    fact[idp - 1] - fact[ie] - fact[nlmp - 1] -
                    fact[igp - 1] - fact[ihp - 1] - fact[iip - 1]);
            if (x >= dummy) {
                goto L160;
            }
            sumprb = x;
            y = x;


y is never checked for zero and later on

L150:
            if (lsm) {
                goto L155;
            }

            /* Decrement entry in row L, column M */
            j = nll * (ii + nll);
            if (j == 0) {
                goto L154;
            }
            --nll;
            y = y * j / (double) ((id - nll) * (ia - nll));
            sumprb += y;
            if (sumprb >= dummy) {
                goto L159;
            }
            if (! lsp) {
                goto L140;
            }
            goto L150;


y has no chance of becoming larger than zero and we are in the goto trap
until the end of time. A simple fix would be checking for zero but I don't
know how one would proceed in this case ...

Best,

Torsten

>>>>> "Jeffrey" == Jeffrey Chang <jeffrey.chang at
duke.edu>
>>>>>     on Thu, 11 Dec 2003 09:58:43 -0500 writes:
    Jeffrey> Hello everybody, I'm running R 1.8.1 on both Linux
    Jeffrey> and OS X compiled with gcc 3.2.2 and 3.3,
    Jeffrey> respectively.  The following call seems to freeze
    Jeffrey> the interpreter on both systems:
    >> chisq.test(matrix(c(233, 580104, 3776, 5786104), 2, 2),
    >> simulate=TRUE)

    Jeffrey> By freeze, I mean, the function call never returns
    Jeffrey> (running > 10 hours so far), the process is
    Jeffrey> unresponsive to SIGINT (but I call kill it with
    Jeffrey> TERM), and the process still consumes cycles on the
    Jeffrey> CPU.

    Jeffrey> Browsing through the code, it seems to be getting
    Jeffrey> stuck on the C call to "chisqsim" .

that's true

    Jeffrey> Has anyone seen this, or know what may be causing
    Jeffrey> it?

I can reproduce it and am pretty sure, the reason is 
integer overflow or something of that nature.

I've recently been looking at a similar bug with fisher.test()
(returning p.value = Inf !) and reason *was* integer overflow
{fix not yet committed}.

--> I'll have a look at this, as well.

Martin Maechler <maechler at stat.math.ethz.ch>
http://stat.ethz.ch/~maechler/
Seminar fuer Statistik, ETH-Zentrum  LEO C16	Leonhardstr. 27
ETH (Federal Inst. Technology)	8092 Zurich	SWITZERLAND
phone: x-41-1-632-3408		fax: ...-1228			<><