similar to: (PR#1242) copy metafile from window() device fails when

Dear all, I'm running into a rather strange problem that hasn't happened before R-1.4.0. If I make a plot on a window() device, and use the menu to either save to a metafile or copy to clipboard as a metafile, I get an error message in the R console: Error: A metafile can store only one figure. This only happens when the lattice (and grid) package is attached, regardless of whether the

Dear colleagues: I use R 1.9.0 on Windows XP. One of my common tasks is to get R graphs into Word documents. A open windows() device, almost always trellis.device() for me, provides great convenience with the right-click shortcut menu item "Copy as metafile". I typically have the History > Recording feature turned on as well. Since upgrading to 1.9.0, I have experienced an

Thanks very much to Paul Murrell and Frank Harrell for addressing my original query (repeated at end of this note). Paul's helpful suggestion with print.trellis and its more= argument, followed by trellis settings, works precisely as I needed. > # snipped from Paul's reply: > p1 <- xyplot(y ~ x, ylim=c(-5, 5)) > p2 <- xyplot(y2 ~ x, pch=16, ylim=c(-5, 5), ylab="

Dear R-devel, I've run into this problem that when I hit c-c to interrupt a command or computation, the R session just ends. The info: R-1.4.1 compiled from source on Linux Mandrake 7.1. Dual P-3 Xeon with 2GB ram. 1. Compiled R with link to Intel Math Kernel Library (for fast BLAS), which needed pthread. C-c at the R prompt ends the R session. 2. Compiled R with link to (threaded)

Dear R-help, Has anyone tried linking R against the Intel Math Kernel Library on (obviously) Intel architecture? Since MKL claimed to provide optimized BLAS and Lapack, I thought it might be possible to compile R against it w/o too much trouble. My first naive try under Linux (Mandrake 7.1), using R-patched dated Jan. 4, 2002: ./configure --with-blas=/usr/local/intel/mkl/LIB/libmkli32_p3.a

I know I should not mix base plotting functions with grid/lattice functions, but I have used a "quick-and-dirty" trick of par(new=T) in the past for annotating a trellis-drawn graph in various versions of S-PLUS. The sequence goes something like this: > windows(width = 5, height = 5, pointsize = 10) # open up the device > xyplot(y ~ x) > par(new=T) > xyplot(y2 ~ x) >

Dear R-devel, Last week I got several responses to my question about debugging segfaults in my code (original post below). After I changed the S_alloc() calls to Calloc()/Free(), the symptom was gone, but I was told to keep looking. So I did: o Switched to Calloc/Free. Electric Fence did not find any problem. o Put assert(index < bound); assert(index >=0); everywhere in the C routine

Dear R-help, I'm having problem creating a dll using Rcmd SHLIB with R-1.3.1 on WinNT4: C:\TEMP>Rcmd SHLIB tryf.o make[1]: `libR.a' is up to date. make: *** No rule to make target `'tryf.o', needed by `tryf.a'. Stop. C:\TEMP>Rcmd SHLIB tryf.f make[1]: `libR.a' is up to date. make: *** No rule to make target `'tryf.o', needed by `tryf.a'. Stop. I

Dear R-help, I'm having problem creating a dll using Rcmd SHLIB with R-1.3.1 on WinNT4: C:\TEMP>Rcmd SHLIB tryf.o make[1]: `libR.a' is up to date. make: *** No rule to make target `'tryf.o', needed by `tryf.a'. Stop. C:\TEMP>Rcmd SHLIB tryf.f make[1]: `libR.a' is up to date. make: *** No rule to make target `'tryf.o', needed by `tryf.a'. Stop. I

Hi all, I've compiled R-1.4.0 on my NT box with link against ATLAS. It has passed all the Rcmd CHECK that I could run. If there's sufficient interest, I can make the SetupR.exe available (on CRAN?). Just drop me a note if you're interested. Note the following: o I can only connect thru 56K dial-up until Jan. 2, 2002, so unless there's overwhelming demand, I won't attempt

(Sorry for the cross-post--- I wasn't sure which list is more appropriate...) Hi everyone, I've run into segfaults when using my randomForest package on large dataset (e.g., 100 x 15200) and large number of trees (e.g., ntree=7000 and mtry=3000). I'm wondering if anyone can give me some hints on where to look for the problem. The randomForest package mainly consists of two things:

(Sorry for the cross-post--- I wasn't sure which list is more appropriate...) Hi everyone, I've run into segfaults when using my randomForest package on large dataset (e.g., 100 x 15200) and large number of trees (e.g., ntree=7000 and mtry=3000). I'm wondering if anyone can give me some hints on where to look for the problem. The randomForest package mainly consists of two things:

Hi all, There is now a package available on CRAN that provides an R interface to Leo Breiman's random forest classifier. Basically, random forest does the following: 1. Select ntree, the number of trees to grow, and mtry, a number no larger than number of variables. 2. For i = 1 to ntree: 3. Draw a bootstrap sample from the data. Call those not in the bootstrap sample the

Hi all, There is now a package available on CRAN that provides an R interface to Leo Breiman's random forest classifier. Basically, random forest does the following: 1. Select ntree, the number of trees to grow, and mtry, a number no larger than number of variables. 2. For i = 1 to ntree: 3. Draw a bootstrap sample from the data. Call those not in the bootstrap sample the

Dear all: Professor Ripley commented: > Note that libEMF's help page says > > It is also possible now to generate EMF files from PSTOEDIT > on POSIX > systems. Therefore, if your graphics code only outputs > PostScript, you > can now easily convert it to EMF. > > but that is only true on Windows (unfortunately). > Actually I have had some luck

Hi all, Thanks to Prof. Ripley, Prof. Gentleman, and Simon Wood (did I miss anyone?). The problem seemed to have gone away. Everyone suggested using some malloc debugger (such as Electric Fence). All I did was following half of what BDR suggested below, i.e., changing all the S_alloc() calls to Calloc() and Free(). I didn't get to try efence, and the problem seems to have disappeared! As

Hi all, I develop and print from both Windows and Linux, and am seeing some printing inconsistencies first described about a year and a half ago by Andy Liaw (see below). Specifically, the line widths on my windows plots are about 5 times smaller than that on Linux, and my windows printouts do not match what my screen looks like. However, if I print to a pdf file first, then I can get accurate

... Moved from R-help ... Thank you for your suggestion, Professor Ripley. Postscript does seem like the way to go for printing line widths correctly in Windows. On Linux I am using a simple dev.print() wrapper (as suggested), with a pipe to lpr. However, I had an extremely difficult time getting postscript printing under windows. ?postscript recommends the RedMon suite of tools for printing

Dear R-help, Has anyone notice the problem that, on Windows (NT and XP), when printing a graph using the "File -> Print..." menu in the graphics window to print the graph, that line width seemed to be ignored in the printed output? For example, if I make a plot with plot(1:10, type="l", lwd=5), it looks right on screen, but when printed out using the menu, it looks like

Dear R-devel, Has anyone played with this? http://www.amd.com/us-en/Processors/DevelopWithAMD/0,,30_2252_2282,00.html <http://www.amd.com/us-en/Processors/DevelopWithAMD/0,,30_2252_2282,00.html> . I'll probably give it a shot... Best, Andy Andy Liaw, PhD Biometrics Research PO Box 2000, RY33-300 Merck Research Labs Rahway, NJ 07065 mailto:andy_liaw@merck.com