[Rd] chisq.test() and r2dtable() freezing on certain inputs (PR#5701)

[maechler at stat.math.ethz.ch]

>>>>> "MM" == Martin Maechler <maechler at stat.math.ethz.ch>
>>>>>     on Thu, 11 Dec 2003 18:29:05 +0100 (CET) writes:

>>>>> "Torsten" == Torsten Hothorn <torsten at hothorn.de>
>>>>>     on Thu, 11 Dec 2003 18:03:07 +0100 (CET) writes:

    Torsten> 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.
    >>> 

    Torsten> This is due to calling `exp' with a very small
    Torsten> value leading to a zero return value in rcont2
    Torsten> (src/appl/rcont.c) line 70:

    MM> yes, that's correct.

However, as I have found out now, the real reason *is* integer
overflow (in multiplication), as I had guessed originally (but
didn't believe anymore for a while after your exp() underflow diagnosis).
Note that this also affects  r2dtable(), and e.g., the following
gives a segmentation fault:

M <- 50000 ; r2dtable(1, c(2*M,3), M+1:2)

Further, even if I protect against the exp() underflow, I can
still see examples which "freeze", i.e. end in an infinite loop.

-------

The fix is to ensure that integer multiplications i * j  do not happen
but rather    i * (double) j

I will commit a fix to R-patched and R-devel later this evening.

-- 
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			<><