On Mon, Jan 31, 2011 at 3:18 PM, Prof Brian Ripley <rip...@stats.ox.ac.uk> wrote: > On Mon, 31 Jan 2011, ken.willi...@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.willi...@thomsonreuters.com >> http://labs.thomsonreuters.com >> >> >> >> >> >> On 1/31/11 1:48 PM, "Prof Brian Ripley" <rip...@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, rip...@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@r-project.org mailing list >>> https://stat.ethz.ch/mailman/listinfo/r-devel >>> >> >> > > -- > Brian D. Ripley, rip...@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@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
