Re: [Rd] pairs(oma) warnings (PR#8252)

On Wed, 26 Oct 2005 [EMAIL PROTECTED] wrote: > Unlike R 2.1.1, version 2.2.0 generates warnings when an 'oma' argument as > passed to pairs(): > > A <- rnorm(100) > B <- rnorm(100) > pairs(cbind(A,B))# no warning > pairs(cbind(A,B), oma=c(6,8,10,12)) # warnings in R 2.2.0

[Rd] pairs(oma) warnings (PR#8252)

Unlike R 2.1.1, version 2.2.0 generates warnings when an 'oma' argument as passed to pairs(): A <- rnorm(100) B <- rnorm(100) pairs(cbind(A,B))# no warning pairs(cbind(A,B), oma=c(6,8,10,12)) # warnings in R 2.2.0 I think pairs() should draw the plot quietly, without

Re: [Rd] error from make: gcc -shared -L/usr/local/lib64 ... relocation R_X86_64_32...

Dear Peter and Brian, I have made progress. I removed libf2c and installed it again. Then libg2c.so.0 ended up in /usr/lib64. make is getting much further now. I think I had a messed up installation of the development packages, maybe. Weird. Anyway, I appreciate all your great help. Cheers

Re: [Rd] error from make: gcc -shared -L/usr/local/lib64 ... relocation R_X86_64_32...

Prof Brian Ripley <[EMAIL PROTECTED]> writes: > It is libg2c.a you are being told to recompile. > > There ought to be a lib2gc.so* on your system. On FC3 > > gannet% rpm -q --whatprovides /usr/lib/libg2c.so.0 > libf2c-3.4.4-2.fc3 > gannet% rpm -q --filesbypkg libf2c-3.4.4-2.fc3 > libf2c

Re: [Rd] error from make: gcc -shared -L/usr/local/lib64 ... relocation R_X86_64_32...

Dick Beyer <[EMAIL PROTECTED]> writes: > I hope someone can point me, a newcomer to building R as well as 64-bit R, in > a useful direction. I have a dual Opteron 275 box running RedHat EL4. I ran > configure successfully, and, then, get the following error while running make: > > make[4]: En

Re: [Rd] error from make: gcc -shared -L/usr/local/lib64 ... relocation R_X86_64_32...

It is libg2c.a you are being told to recompile. There ought to be a lib2gc.so* on your system. On FC3 gannet% rpm -q --whatprovides /usr/lib/libg2c.so.0 libf2c-3.4.4-2.fc3 gannet% rpm -q --filesbypkg libf2c-3.4.4-2.fc3 libf2c/usr/lib/libg2c.so.0 libf2c/usr

Re: [Rd] strptime problem for 2004-10-03 02:00:00

It's a bug, a rather rare one. 2004-10-03 02:00:00 does not exist in your time zone, and in trying to find out if the time is on DST or not it has failed to find out. It needs to be told that GMT is never on DST so not to bother. On Linux, running R with TZ="GMT" set should fix this. Windows

[Rd] error from make: gcc -shared -L/usr/local/lib64 ... relocation R_X86_64_32...

I hope someone can point me, a newcomer to building R as well as 64-bit R, in a useful direction. I have a dual Opteron 275 box running RedHat EL4. I ran configure successfully, and, then, get the following error while running make: make[4]: Entering directory `/tmp/R-2.2.0/src/modules/lapack'

Re: [Rd] download problem: Windows binaries - patched/devel versions

Hello, > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Duncan Murdoch > Sent: Monday, October 24, 2005 7:04 PM > To: P Ehlers > Cc: r-devel@stat.math.ethz.ch > Subject: Re: [Rd] download problem: Windows binaries - > patched/devel versions > > P

[Rd] MiKTeX/yap/Ghostcript issues with R-generated postscript" (continue)

Hi, I have the problem which resembles the situation described in " [Rd] MiKTeX/yap/Ghostcript issues with R-generated postscript " I run MikTeX 2.4 with Yap as dvi viewer and Ghostscript 8.15. Some latex files with pstricks code i

Re: [Rd] performance of nchar

On Tue, 25 Oct 2005, Jennifer Lai wrote: > Hi, >Is nchar function knowingly slow in R? I'm doing some string > formatting that requires multiple call to nchar, and nchar seems to be > very slow. Is 70 usec 'very slow'? Both nchar and sprintf are vectorized, so why not make use of that? > st

[Rd] performance of nchar

Hi, Is nchar function knowingly slow in R? I'm doing some string formatting that requires multiple call to nchar, and nchar seems to be very slow. Experiment 1, pass nchar inside sprintf, and it takes 0.7 seconds > system.time(for (i in 1:1) + str = sprintf('0005%020d', nchar(op)) + )[3

Re: [Rd] Small issue with R's C API

Prof Brian Ripley wrote: > An R NULL does not map to a C NULL. > > Please learn to distinguish documented facts from uninformed guesswork. Any probably it should be added that users should not look at Rinternals.h, because they will find things like NILSXP that are defined to be 0 (C NULL). __

Re: [Rd] Small issue with R's C API

An R NULL does not map to a C NULL. Please learn to distinguish documented facts from uninformed guesswork. On Tue, 25 Oct 2005, Dominick Samperi wrote: > Prof Brian Ripley wrote: >> This is nothing to do with the C API: isVector and isMatrix are not >> part of the API (see Writing R Extensions

Re: [Rd] How to uninstall R when installed with "make install"

On Tue, 25 Oct 2005, Rainer M. Krug wrote: > How can I uninstall R when I installed it with "make install"? Did you try 'make uninstall' as the manual says? Works for me. -- Brian D. Ripley, [EMAIL PROTECTED] Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/

[Rd] How to uninstall R when installed with "make install"

Hi How can I uninstall R when I installed it with "make install"? Thanks, Rainer -- NEW TELEPHONE NUMBER Tel:+27 - (0)72 808 2975 (w) Rainer M. Krug, Dipl. Phys. (Germany), MSc Conservation Biology (UCT) Department of Conservation Ecology University of Stellenbosch Matieland 760

[Rd] native logistic regression

Hello, thanks for the answers to my last questions and apologies for not seeing the answers staring me down in the manual. At the risk of asking another potentially obvious question ... we are currently using some of the NAG routines for model fitting and I am trying to re-write the relevant po

[Rd] Noncentral problems in pf() (PR#8251)

Full_Name: Ken Kelley Version: 2.2 OS: Windows XP Submission from: (NULL) (156.56.3.241) It seems that the pf() function when used with noncentral parameters can behave badly at times. I've included some examples below, but what is happening is that with some combinations of df and ncp paramete

Re: [Rd] Small issue with R's C API

Prof Brian Ripley wrote: > This is nothing to do with the C API: isVector and isMatrix are not > part of the API (see Writing R Extensions for what it is). That's the > `issue' here. > > On Tue, 25 Oct 2005, Dominick Samperi wrote: > >> Consider the R code: >> mat <- matrix(seq(1,20),4,5) >> is.

Re: [Rd] Small issue with R's C API

Prof Brian Ripley wrote: > This is nothing to do with the C API: isVector and isMatrix are not > part of the API (see Writing R Extensions for what it is). That's the > `issue' here. > > On Tue, 25 Oct 2005, Dominick Samperi wrote: > >> Consider the R code: >> mat <- matrix(seq(1,20),4,5) >> is.

Re: [Rd] Small issue with R's C API

This is nothing to do with the C API: isVector and isMatrix are not part of the API (see Writing R Extensions for what it is). That's the `issue' here. On Tue, 25 Oct 2005, Dominick Samperi wrote: > Consider the R code: > mat <- matrix(seq(1,20),4,5) > is.matrix(mat) # gives TRUE > is.vector(m

[Rd] Small issue with R's C API

Consider the R code: mat <- matrix(seq(1,20),4,5) is.matrix(mat) # gives TRUE is.vector(mat) # gives FALSE On the other hand, if mat is passed through the .Call interface the corresponding SEXP (call it smat) satisfies isMatrix(smat) // TRUE isVector(smat) // TRUE Consequently, you cannot dist

Re: [Rd] Rgnome depends on obsolete components libglade/libxml (PR#8247)

Marc Schwartz (via MN) wrote: > This brings us full circle to the whole GUI discussion taking place and > so I'll leave it for that thread. That's unfortunately correct. The three GUI's (out of the dozen listed at R-GUI FAQ) I have so far looked into, are all somewhat "officially" endorsed: (1)

Re: [Rd] Rgnome depends on obsolete components libglade/libxml (PR#8247)

Marc Schwartz (via MN) wrote: > This brings us full circle to the whole GUI discussion taking place and > so I'll leave it for that thread. That's unfortunately correct. The three GUI's (out of the dozen listed at R-GUI FAQ) I have so far looked into, are all somewhat "officially" endorsed: (1)