From hwborchers at gmail.com  Wed Jul 17 21:35:39 2013
From: hwborchers at gmail.com (Hans W Borchers)
Date: Wed, 17 Jul 2013 21:35:39 +0200
Subject: [Rd] Problem following an R bug fix to integrate()
In-Reply-To: <1374082630.2272.43.camel@braque.iarc.fr>
References: <CAML4n3P5tekMoE+k3287tm+BDy5DqqwK=bXx4j1shwEuAPeyQw@mail.gmail.com>
	<1374082630.2272.43.camel@braque.iarc.fr>
Message-ID: <CAML4n3OT5FhJjY8Y+NBu4s2F2moL1VrBDGz7YMp=V=v49bdwoA@mail.gmail.com>

Thanks for the help.

What bothers me is that it works on most systems and does not work on
some more 'exotic' systems -- though it should work everywhere however
small the user chooses the tolerance (with some warnings, maybe).

I decided I will apply my own integration routines in this example as
they appear to work more reliably.

Hans Werner


On Wed, Jul 17, 2013 at 7:37 PM, Martyn Plummer <plummerm at iarc.fr> wrote:
> On Tue, 2013-07-16 at 13:55 +0200, Hans W Borchers wrote:
>> I have been told by the CRAN administrators that the following code generated
>> an error on 64-bit Fedora Linux (gcc, clang) and on Solaris machines (sparc,
>> x86), but runs well on all other systems):
>>
>>     > fn <- function(x, y) ifelse(x^2 + y^2 <= 1, 1 - x^2 - y^2, 0)
>>
>>     > tol <- 1.5e-8
>>     > fy <- function(x) integrate(function(y) fn(x, y), 0, 1,
>>                             subdivisions = 300, rel.tol = tol)$value
>>     > Fy <- Vectorize(fy)
>>
>>     > xa <- -1; xb <- 1
>>     > Q  <- integrate(Fy, xa, xb,
>>                 subdivisions = 300, rel.tol = tol)$value
>>
>>     Error in integrate(Fy, xa, xb, subdivisions = 300, rel.tol = tol) :
>>     roundoff error was detected
>>
>> Obviously, this realizes a double integration, split up into two 1-dimensional
>> integrations, and the result shall be pi/4. I wonder what a 'roundoff error'
>> means in this situation.
>>
>> In my package, this test worked well, w/o error or warnings, since July 2011,
>> on Windows, Max OS X, and Ubuntu Linux. I have no chance to test it on one of
>> the above mentioned systems. Of course, I can simply disable these tests, but
>> I would not like to do so w/o good reason.
>>
>> If there is a connection to a bug fix to integrate(), with NEWS item
>>
>>     "integrate() reverts to the pre-2.12.0 behaviour.  (PR#15219)",
>>
>> then I do not understand what this pre-2.12.0 behavior really means.
>>
>> Thanks for any help or a hint to what shall be changed.
>
> You can see the bug report here:
>
> https://bugs.r-project.org/bugzilla3/show_bug.cgi?id=15219
>
> It concerns the behaviour of integrate with a small error tolerance.
> From 2.12.0 to 3.0.1 integrate was not working correctly with small
> error tolerance values, in the sense that small values did not improve
> accuracy and the accuracy was mis-reported.
>
> The tolerance in your example (1.5e-8) is considerably smaller than the
> default (1.2e-4). My guess is that the rounding error always existed but
> was not detected due to the bug.  You might try a larger tolerance. I
> have tested your example and increasing the tolerance to 1.5e-7 removes
> the error.
>
> Martyn
>
>
>> Hans W Borchers
>>
>> PS:
>> This kind of tricky definition in function 'fn' has caused some discussion on
>> this list in July 2009. I still think it should be allowed to proceed in this
>> way.
>>
>> ______________________________________________
>> R-devel at r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>
> -----------------------------------------------------------------------
> This message and its attachments are strictly confiden...{{dropped:8}}



[Rd] Problem following an R bug fix to integrate()
Hans W Borchers