>>>>> "PetRd" == Peter Ruckdeschel <[EMAIL PROTECTED]>
>>>>> 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 <[EMAIL PROTECTED]>
>>>>>>> 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
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
