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 <djsamp...@gmail.com>
wrote:
      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




--
______________________________________________________

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

Reply via email to