similar to: Using influence plots and obtaining id numbers

Dear all, I'm a newbie in R. I am running simulations using a fixed bandwidth in nonparametric regressions, sending all the output to a file myoutput.txt using sink("myoutput.txt"), & R is printing all warnings by the end of the simulation on the file. I know the source of the problem & can take care of it. However, finding a 50 MB file (where all the output is printed, e.g.

Dear all, The basename() function returns the extension also: > myfile <- "path1/path2/myoutput.txt" > basename(myfile) [1] "myoutput.txt" Is there any other function where it just returns plain base: "myoutput" i.e. without 'txt' - Gundala Viswanath Jakarta - Indonesia

Hello, I tried to call an external function of R from the following code in C++: void prodgdot(double *x, double *y, int *n, double *output) { int i; *output=0; for (i=0;i<*n;i++) { *output+=x[i]*y[i]; } } I compiled it using from my working directory in linux terminal and I think it's ok: giba at giba-desktop:~/mysrc/meus_testes_iniciais$ R CMD SHLIB

dear R wizards---I must be standing on the line (German translation---this must be obvious). This is probably embarrassingly obvious to anyone, except to me right now. maybe it is late. I would like to run my R code in batch, but not see the R compilations and my R source code---I just want to see the same output that I would see if I ran source("i.R"), but direct it to a file. I can

Dear all, Every time that I need to generate I plot output as figure I use something like png("myoutput.png") plot(rnorm(100)*1.0,col=4) points(rnorm(100)*0.5,col=2,pch=0) dev.off() But now I need to generate a lot of outputs and it could not be done in a for looping where I can change the names. So I would like to know if is there a way of I automatically redirect the output from my

On Mon, Feb 21, 2011 at 03:58:19PM -0800, Eric Christopher wrote: > > On Feb 19, 2011, at 11:25 AM, Jack Howarth wrote: > > > Is anyone able to bootstrap llvm-gcc42 svn on x86_64-apple-darwin10? Currently it is > > failing here with... > > It was broken. I think I've fixed it in reverting 125960. > > -eric Eric, The llvm-gcc42 bootstrap is fixed in

Comparing the Polyhedron 2005 benchmark results for gfortran from llvm-gcc-4.2 of April 7th, 2010 and September 18th, 2010 (from the rc2 2.8 release branch), we seem to be regressing in performance for this release.... ================================================================================ Date & Time : 7 Apr 2010 22:24:16 Test Name : llvm_gfortran_lin_p4 Compile Command :

On Thu, Apr 08, 2010 at 08:45:48AM -0700, Bob Wilson wrote: > [CCing Dale since this was his change, not mine] > > The change in 81455 fixes a compiler crash. It doesn't happen very often, but I can't imagine we would want to back that out. Fixing it would be a more reasonable solution. From a quick look at it, the problem is that gcc/config/darwin-c.c is registering va_opt

On Apr 7, 2010, at 8:41 PM, Jack Howarth wrote: > Building the current release 2.7 branch on x86_64-apple-darwin10 > with r81455 reverted, I get the following Polyhedron 2005 benchmark > results (with no test failures)... Very nice! A 14% speedup on a benchmark we don't tune for isn't bad. I imagine that there are several easy wins you could get on it if you were interested

On Apr 8, 2010, at 8:45 AMPDT, Bob Wilson wrote: > [CCing Dale since this was his change, not mine] > > The change in 81455 fixes a compiler crash. It doesn't happen very often, but I can't imagine we would want to back that out. Fixing it would be a more reasonable solution. From a quick look at it, the problem is that gcc/config/darwin-c.c is registering va_opt for GC.

Building the current release 2.7 branch on x86_64-apple-darwin10 with r81455 reverted, I get the following Polyhedron 2005 benchmark results (with no test failures)... ================================================================================ Date & Time : 7 Apr 2010 22:24:16 Test Name : llvm_gfortran_lin_p4 Compile Command : llvm-gfortran -ffast-math -funroll-loops -msse3

[CCing Dale since this was his change, not mine] The change in 81455 fixes a compiler crash. It doesn't happen very often, but I can't imagine we would want to back that out. Fixing it would be a more reasonable solution. From a quick look at it, the problem is that gcc/config/darwin-c.c is registering va_opt for GC. When you build for Fortran, darwin-c.o is not linked so the GC gets

On Wed, Apr 07, 2010 at 09:54:36PM -0700, Chris Lattner wrote: > > On Apr 7, 2010, at 8:41 PM, Jack Howarth wrote: > > > Building the current release 2.7 branch on x86_64-apple-darwin10 > > with r81455 reverted, I get the following Polyhedron 2005 benchmark > > results (with no test failures)... > > Very nice! A 14% speedup on a benchmark we don't tune for

I am finding with the patch that all of the Polyhedron 2005 benchmarks pass on i686-apple-darwin9. Could someone clarify the regression rules for releases? Not building a secondary language on a primary target is usually considered a P1 regression for FSF gcc. Not doing so here gives one the impression that llvm.org isn't playing by the same rules. No one is ever going to want to use these