On Wed, Feb 2, 2011 at 6:03 AM, Prof Brian Ripley wrote:
> 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)
>
> Pl
I can confirm that the problem is not present anymore in R-patched,
same box as before, compiled with standard optimizations flags.
thank you
Simone
gcc (SUSE Linux) 4.5.0 20100604 [gcc-4_5-branch revision 160292]
> sessionInfo()
R version 2.12.1 Patched (2011-02-01 r54197)
Platform: x86_64-un
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.
P
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)
Platform: x86_64-unknown-linux-gnu (64-bit)
locale:
[1] LC_CTYPE=en_US.UTF-8 LC_NUMERIC=C
[3] LC_TIME=en_US.UTF-8
On Mon, Jan 31, 2011 at 3:18 PM, Prof Brian Ripley
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
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
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 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 resul
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 co