search for: 0.837

Dear R users, I'm currently using the Graphics package to display several hundred of matrix objects, using a layout and the image() function. It works well except for large matrices (> 1000*1000) or for a large number of matrices (there is a limitation around 400 if I remember well) To solve these issues, I move to the Matrix package which is much more efficient for large sparse matrix,

Dear List: the CODA and BOA packages for the analysis of MCMC output yield different results on two dignostic test of convergence: 1) Geweke's convergence diagnostic; 2) Heidelberger and Welch's convergence diagnostic. Does that imply that the CODA and BOA packages implement different ``flavors'' of the same test? I paste below an example. Geweke's test

Hi, I just read the "Embedding R in Gnumeric" idea at http://www.r-project.org/SoC08/ideas.html. On my side, I intend to add as many statistics related plot types to the current gnumeric charting engine as possible. We already have boxplots and partial support for histograms. My immediate plans are to finish the histogram code and add probability plots

Dear Thomas, The head of my dataset > head(wsuv) parcel sp time censo treatment species 1 S8 Poecilanthe effusa ( Hub. ) Ducke. 1 1 1 1 2 S8 Poecilanthe effusa ( Hub. ) Ducke. 1 1 1 1 3 S8 Poecilanthe effusa ( Hub. ) Ducke. 1 1 1 1 4 S8 Poecilanthe effusa ( Hub. ) Ducke. 1 1 1

Dear useRs, I reran an analysis with bam (mgcv, version 1.7-17) originally conducted using an older version of bam (mgcv, version 1.7-11) and this resulted in the same estimates, but much lower standard errors (in some cases 20 times as low) and lower p-values. This obviously results in a larger set of significant predictors. Is this result expected given the improvements in the new version? Or

Hello, I'm trying to analyse data from an incomplete design with four factor : - fr : number of the batch - op : ID of operator - meth : method used - mat : nature of the material used and one variable - mv : mesure - trmv : transformed mesure str(matvol) `data.frame': 120 obs. of 6 variables: $ fr : Factor w/ 30 levels "1","2","3","4",..:

Hi, I have a follow analysis Trat1 = quantitative variable Trat2 = qualitative variable with 3 levels (A, B, C) Trat3 = qualitative variable with 3 levels (D, E, F) Resp = Response I try to get the parameters to compare with zero, so I make this model: glm(Resp~Trat1*Trat2+Trat1*Trat3-Trat1-1) The -Trat1 is to make comparison of slope with zero. The -1 is to make comparison os intercept with

Dear R folk: Perhaps I'm just dense today, but I am having trouble reproducing the principal components plotted and summarized by clusplot. Here is a brief example using the pluton dataset. clusplot reports that the first two principal components explain 99.7% of the variability. But this is not what princomp is reporting. I would greatly appreciate any advice. With best regards, -- Tom

Dear R users: I'm generating the following survival data: set.seed(123) n=200 #sample size x=rbinom(n,size=1,prob=.5) #binomial treatment v=rgamma(n,shape=1,scale=1) #gamma frailty w=rweibull(n,shape=1,scale=1) #Weibull deviates b=-log(2) #treatment's slope t=exp( -x*b -log(v) + log(w) ) #failure times c=rep(1,n) #uncensored indicator id=seq(1:n) #individual frailty indicator

On 03/19/2013 11:02 AM, Star Tan wrote: > > Dear Tobias Grosser, > > Today I have rebuilt the LLVM-Polly in Release mode. The configuration of my own testing machine is: Intel Pentium Dual CPU T2390(1.86GHz) with 2GB DDR2 memory. > I evaluated the Polly using PolyBench and Mediabench. It takes too long time to evaluate the whole LLVM-testsuite, so I just choose the Mediabench from

Dear Tobias Grosser, Today I have rebuilt the LLVM-Polly in Release mode. The configuration of my own testing machine is: Intel Pentium Dual CPU T2390(1.86GHz) with 2GB DDR2 memory. I evaluated the Polly using PolyBench and Mediabench. It takes too long time to evaluate the whole LLVM-testsuite, so I just choose the Mediabench from LLVM-testsuite. The preliminary results of Polly compiling

On Wed, Oct 11, 2017 at 2:34 PM, Tom Lendacky <thomas.lendacky at amd.com> wrote: > On 10/11/2017 3:30 PM, Thomas Garnier wrote: >> Changes: >> - patch v1: >> - Simplify ftrace implementation. >> - Use gcc mstack-protector-guard-reg=%gs with PIE when possible. >> - rfc v3: >> - Use --emit-relocs instead of -pie to reduce dynamic

On Wed, Oct 11, 2017 at 2:34 PM, Tom Lendacky <thomas.lendacky at amd.com> wrote: > On 10/11/2017 3:30 PM, Thomas Garnier wrote: >> Changes: >> - patch v1: >> - Simplify ftrace implementation. >> - Use gcc mstack-protector-guard-reg=%gs with PIE when possible. >> - rfc v3: >> - Use --emit-relocs instead of -pie to reduce dynamic

Hi all, I'm working with a bunch of large graphs, and stumbled across something useful. Probably many of you know this, but I didn't and so others might benefit. Using pch="." speeds up plotting considerably over using symbols. > x <- runif(1000000) > y <- runif(1000000) > system.time(plot(x, y, pch=".")) user system elapsed 1.042 0.030 1.077

Dear Tobias Grosser, Thank you so much for your kind reply. Your advice is very helpful and inspiring. At 2013-03-18 20:40:50,"Tobias Grosser" <tobias at grosser.es> wrote: >On 03/17/2013 11:54 PM, Star Tan wrote: >> Hello Tobi, >> >> I am interested in Polly project. Polly seems to be a very promising tool to find out program parallelization based on LLVM

On 10/11/2017 3:30 PM, Thomas Garnier wrote: > Changes: > - patch v1: > - Simplify ftrace implementation. > - Use gcc mstack-protector-guard-reg=%gs with PIE when possible. > - rfc v3: > - Use --emit-relocs instead of -pie to reduce dynamic relocation space on > mapped memory. It also simplifies the relocation process. > - Move the start the module

On 10/12/2017 10:34 AM, Thomas Garnier wrote: > On Wed, Oct 11, 2017 at 2:34 PM, Tom Lendacky <thomas.lendacky at amd.com> wrote: >> On 10/11/2017 3:30 PM, Thomas Garnier wrote: >>> Changes: >>> - patch v1: >>> - Simplify ftrace implementation. >>> - Use gcc mstack-protector-guard-reg=%gs with PIE when possible. >>> - rfc

Dear Tobies, Sorry for the late reply. I have checked the experiment and I found some of the data is mismatched because of incorrect manual copy and paste, so I have written a Shell script to automatically collect data. Newest data is listed in the attached file. Tobies, I have made a simple HTML page (attached polly-compiling-overhead.html) to show the experimental data and my plans for this

Changes: - patch v1: - Simplify ftrace implementation. - Use gcc mstack-protector-guard-reg=%gs with PIE when possible. - rfc v3: - Use --emit-relocs instead of -pie to reduce dynamic relocation space on mapped memory. It also simplifies the relocation process. - Move the start the module section next to the kernel. Remove the need for -mcmodel=large on modules. Extends

Changes: - patch v1: - Simplify ftrace implementation. - Use gcc mstack-protector-guard-reg=%gs with PIE when possible. - rfc v3: - Use --emit-relocs instead of -pie to reduce dynamic relocation space on mapped memory. It also simplifies the relocation process. - Move the start the module section next to the kernel. Remove the need for -mcmodel=large on modules. Extends