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

[Prof Brian Ripley]

On Wed, 2 Feb 2011, Simone Giannerini wrote:

> I see the problem on my OpenSuse 11.3 box
> 
> gcc (SUSE Linux) 4.5.0 20100604 [gcc-4_5-branch revision 160292]
> 
> > sessionInfo()
> R version 2.12.1 Patched (2011-01-10 r53953)

Please update this and let us know if it persists with current 
R-patched.

> Platform: x86_64-unknown-linux-gnu (64-bit)

DS failed to tell us his platform, and maybe it was not x86_64.

> locale:
>  [1] LC_CTYPE=en_US.UTF-8       LC_NUMERIC=C             
>  [3] LC_TIME=en_US.UTF-8        LC_COLLATE=en_US.UTF-8   
>  [5] LC_MONETARY=C              LC_MESSAGES=en_US.UTF-8  
>  [7] LC_PAPER=en_US.UTF-8       LC_NAME=C                
>  [9] LC_ADDRESS=C               LC_TELEPHONE=C           
> [11] LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=C      
> 
> attached base packages:
> [1] stats     graphics  grDevices utils     datasets  methods   base   
> 
> > 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))
> Error: all.equal(z2, z0) is not TRUE
> 
> Simone
> 
> 
> On Wed, Feb 2, 2011 at 1:45 AM, Dominick Samperi <djsamperi at gmail.com>
> wrote:
>       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
> >
> 
> ______________________________________________
> R-devel at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
> 
> 
> 
> 
> --
> ______________________________________________________
> 
> Simone Giannerini
> Dipartimento di Scienze Statistiche "Paolo Fortunati"
> Universita' di Bologna
> Via delle belle arti 41 - 40126  Bologna,  ITALY
> Tel: +39 051 2098262  Fax: +39 051 232153
> http://www2.stat.unibo.it/giannerini/
> ______________________________________________________
> 
>

-- 
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