From maechler at stat.math.ethz.ch  Tue Jul  3 17:55:08 2007
From: maechler at stat.math.ethz.ch (Martin Maechler)
Date: Tue, 3 Jul 2007 17:55:08 +0200
Subject: [Rd] minor flaw in integrate()
In-Reply-To: <468A6AB3.60509@uni-bayreuth.de>
References: <46842286.8080402@uni-bayreuth.de> <4689ACC7.6010005@stats.uwo.ca>
	<18058.3245.990602.638911@stat.math.ethz.ch>
	<468A6AB3.60509@uni-bayreuth.de>
Message-ID: <18058.29020.369190.734208@stat.math.ethz.ch>

>>>>> "PetRd" == Peter Ruckdeschel <Peter.Ruckdeschel at uni-bayreuth.de>
>>>>>     on Tue, 03 Jul 2007 17:26:43 +0200 writes:

    PetRd> Thanks Martin and Duncan for your
    PetRd> comments,

    PetRd> Martin Maechler wrote:
    >>>>>>> "DM" == Duncan Murdoch <murdoch at stats.uwo.ca>
    >>>>>>> on Mon, 02 Jul 2007 21:56:23 -0400 writes:
    >> 
    DM> On 28/06/2007 5:05 PM, Peter Ruckdeschel wrote:
    >> >> Hi,
    >> >> 
    >> >> I noticed a minor flaw in integrate() from package stats:
    >> >> 
    >> >> Taking up arguments lower and upper from integrate(),
    >> >> 
    >> >> if (lower ==  Inf) && (upper ==  Inf)
    >> >> 
    >> >> or
    >> >> 
    >> >> if (lower == -Inf) && (upper == -Inf)
    >> >> 
    >> >> integrate() calculates the value for (lower==-Inf) && (upper==Inf).
    >> >> 
    >> >> Rather, it should return 0.
    >> 
    DM> Wouldn't it be better to return NA or NaN, for the same reason Inf/Inf 
    DM> doesn't return 1?
    >> 
    DM> Duncan Murdoch
    >> 
    >> Yes indeed, I think it should return NaN.

    PetRd> not quite convinced --- or more precisely:

    PetRd> [ Let's assume lower = upper = Inf here,
    PetRd> case lower = upper = -Inf is analogue ]

    PetRd> I'd say it depends on whether the (Lebesgue-) integral

    PetRd> integral(f, lower = <some finite value>, upper = Inf)

    PetRd> is well defined. Then, by dominated convergence, the integral should
    PetRd> default to 0.

    PetRd> But I admit that then a test

    PetRd> is.finite(integrate(f, lower = <some finite value>, upper = Inf)$value)

    PetRd> would be adequate, too, which makes evaluation a little more expensive :-(

No, that's not the Duncan's point I agreed on.
The argument is different:

consider       Int(f, x, x^2)
	       Int(f, x, 2*x)
	       Int(f, x, exp(x))
etc, 
These could conceivably give very different values,
with different limits for  x --> Inf

Hence, 	       Int(f, Inf, Inf)

is mathematically undefined, hence NaN
Martin

    PetRd> If, otoh

    PetRd> integrate(f, lower = <some finite value>, upper = Inf)

    PetRd> throws an error, I agree, there should be a NaN ...
    PetRd> Best, Peter



[Rd] minor flaw in integrate()
Martin Maechler