[Rd] Warning: you may need to use R-patched with recent R distros

[Dominick Samperi]

On Mon, Jan 31, 2011 at 3:18 PM, Prof Brian Ripley
<ripley at stats.ox.ac.uk> wrote:
> On Mon, 31 Jan 2011, Ken.Williams at thomsonreuters.com wrote:
>
>> For the complex-numbers bug, do you know a reliable way (besides looking
>> at version numbers) to determine whether the bug is present or absent in a
>> given build?
>
> I know a way: See tests/complex.R in R-devel.
>
> z <- 0.2853725+0.3927816i
> z2 <- z^(1:20)
> z3 <- z^-(1:20)
> z0 <- cumprod(rep(z, 20))
> stopifnot(all.equal(z2, z0), all.equal(z3, 1/z0))
> ## z^3 had value z^2 ....
>

I tried this under Fedora 14 (GCC 4.5.1) using the released R 2.12.1 and
R-devel (2.13.0 devel) and saw no problems? I compared the numbers with
those generated by Octave, took the cube root of z^3 and got z, ran this
unit test and stopifnot did not terminate, etc.

At build time the optimization level was O2.

Dominick

>>
>> I don't know what version of gcc was used in my build nor the optimization
>> flags, so I did a few test exponentiations z^n and the results look okay,
>> but maybe I'm not tickling the right bits.
>>
>>
>> --
>> Ken Williams
>> Senior Research Scientist
>> Thomson Reuters
>> Phone: 651-848-7712
>> ken.williams at thomsonreuters.com
>> http://labs.thomsonreuters.com
>>
>>
>>
>>
>>
>> On 1/31/11 1:48 PM, "Prof Brian Ripley" <ripley at stats.ox.ac.uk> wrote:
>>
>>> Two things have emerged in testing on x86_64 Fedora 14 which mean that
>>> a recent R-patched is probably needed.
>>>
>>> 1) That OS uses zlib 1.2.5: that claims to be binary-compatible with
>>> zlib 1.2.3 but is not, as we found (painfully) on Windows.  The remedy
>>> was to remap _all_ the symbols in R's own copy of zlib (not just those
>>> zlib arranged to remap).
>>>
>>> The symptoms were crashes using packages XML and rgoobi (both of which
>>> link to zlib) and incorrect results in RJaCGH (which contains a copy
>>> of zlib).  There may well be other problems ....
>>>
>>> 2)  Fedora 14 uses gcc 4.5.1. With CFLAGS containing the default -O2
>>> or higher, HAVE_C99_COMPLEX was detected as false because there is a
>>> (genuine) incompatibility between types Rcomplex and C99's double
>>> complex.  This means that R's fallback code is used, and regretably
>>> that contains a serious bug in an 'optimization' by a colleague, so
>>> z^n is incorrect for most complex z and integer n (and has been since
>>> 2.10.0).  The remedy is to use R-patched or R-devel, or only optimize
>>> to -O.
>>>
>>> We've also seen incorrect results from package mvtnorm when C
>>> optimization was -O3.
>>>
>>> The upshot is that there is likely to be a 2.12.2 to fix these issues.
>>>
>>> --
>>> Brian D. Ripley,                  ripley at stats.ox.ac.uk
>>> Professor of Applied Statistics,  http://www.stats.ox.ac.uk/~ripley/
>>> University of Oxford,             Tel:  +44 1865 272861 (self)
>>> 1 South Parks Road,                     +44 1865 272866 (PA)
>>> Oxford OX1 3TG, UK                Fax:  +44 1865 272595
>>>
>>> ______________________________________________
>>> R-devel at r-project.org mailing list
>>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>>
>>
>>
>
> --
> Brian D. Ripley,                  ripley at stats.ox.ac.uk
> Professor of Applied Statistics,  http://www.stats.ox.ac.uk/~ripley/
> University of Oxford,             Tel:  +44 1865 272861 (self)
> 1 South Parks Road,                     +44 1865 272866 (PA)
> Oxford OX1 3TG, UK                Fax:  +44 1865 272595
>
> ______________________________________________
> R-devel at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>