search for: 0.0340

Hi, the following strange error appears when I use qda: > qda1 <- qda(as.data.frame(mfilters[cvtrain,]),as.factor(traingroups)) Error: function is not a closure That's also strange: > qda1 <- qda(mfilters[cvtrain,],as.factor(traingroups)) Error in qda.default(mfilters[cvtrain, ], as.factor(traingroups)) : length of dimnames must match that of dims Some backgroud: >

Dear friends, In R, the help of "bic.glm" tells the difference between postmean(the posterior mean of each coefficient from model averaging) and condpostmean(the posterior mean of each coefficient conditional on the variable being included in the model), But it's still unclear about the results explanations, and the artile of Rnews in 2005 on BMA still don't give more detail on

Hi, One of the most time-consuming passes in LLVM middle-end is InstCombine (see e.g. [1]). It is a very powerful pass capable of doing all the crazy stuff, and new patterns are being constantly introduced there. The problem is that we often use it just as a clean-up pass: it's scheduled 6 times in the current pass pipeline, and each time it's invoked it checks all known patterns. It

On 03/17/2017 04:30 PM, Mehdi Amini via llvm-dev wrote: > >> On Mar 17, 2017, at 11:50 AM, Mikhail Zolotukhin via llvm-dev >> <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: >> >> Hi, >> >> One of the most time-consuming passes in LLVM middle-end is >> InstCombine (see e.g. [1]). It is a very powerful pass capable

Hi, I am new to model selection by coefficient shrinkage method such as lasso. And I became particularly interested in variable selection in Cox regression by lasso. I became aware of the coxpath() in R package glmpath does lasso on Cox model. I have tried the sample script on the help page of coxpath(), but I have difficult time understanding the output. Therefore, I would greatly appreciate if

> On Mar 17, 2017, at 6:12 PM, David Majnemer <david.majnemer at gmail.com> wrote: > > Honestly, I'm not a huge fan of this change as-is. The set of transforms that were added behind ExpensiveChecks seems awfully strange and many would not lead the reader to believe that they are expensive at all (the SimplifyDemandedInstructionBits and foldICmpUsingKnownBits calls being the

> On Mar 17, 2017, at 6:12 PM, David Majnemer via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Honestly, I'm not a huge fan of this change as-is. The set of transforms that were added behind ExpensiveChecks seems awfully strange and many would not lead the reader to believe that they are expensive at all (the SimplifyDemandedInstructionBits and foldICmpUsingKnownBits calls

> To (hopefully) make it easier to answer this question, I've posted my (work-in-progress) patch which adds a known-bits cache to InstCombine. > I rebased it yesterday, so it should be fairly easy to apply: https://reviews.llvm.org/D31239 - Seeing what this does to the performance of the > benchmarks mentioned in this thread (among others) would certainly be interesting. Thanks! I

This may not actually be an R/Splus problem, but it started off that way ..... ===+===+===+===+===+===+===+===+===+===+===+===+===+===+===+===+===+===+=== Executive summary: ================== Simulations involving extreme value distributions seem to ``work'' when the underlying distribution is exponential(1) or exponential(2) == chi-squared_2, but NOT when the underlying distribution is

In my testing results are not that impressive, but that's because I'm now focusing on Os. For me even complete disabling of all KnownBits-related patterns in InstCombine places the results very close to the noise level. In my original patch I also had some extra patterns moved under ExpensiveCombines - and that seems to make a difference too (without this part, or without the KnownBits

Are these 225 compile time regressions real? It sure looks bad! Ciao, Duncan. On 01/12/11 09:39, llvm-testresults at cs.uiuc.edu wrote: > > bwilson__llvm-gcc_PROD__i386 nightly tester results > > URL http://llvm.org/perf/db_default/simple/nts/380/ > Nickname bwilson__llvm-gcc_PROD__i386:4 > Name curlew.apple.com > > Run ID Order Start Time End Time > Current 380