search for: 8.83

Hi, I am trying to convert a dataset (dataframe) into time series object using ts function in stats package. My dataset is as follows: >df [1] 11.08 7.08 7.08 6.08 6.08 6.08 23.08 32.08 8.08 11.08 6.08 13.08 13.83 16.83 19.83 8.83 20.83 17.83 [19] 9.83 20.83 10.83 12.83 15.83 11.83 I converted this into time series object as follows >tsdata <-

Hi, Am I interpreting the results properly? Are my conclusions correct? > KPSS.test(df) ---- ---- KPSS test ---- ---- Null hypotheses: Level stationarity and stationarity around a linear trend. Alternative hypothesis: Unit root. ---- Statistic for the null hypothesis of level stationarity: 1.089 Critical values: 0.10 0.05 0.025 0.01 0.347 0.463

Hello, The problem is that the factors are not orderd by the row number. If you want to check their order, use str(sortdata) and you'll see Santa-Rosa was attributed factor level 4 (in the output, first variable, the 3rd and 4th). Try the following. sortdata <- read.table(text=" county year x1 x2 x3 x4 x5 x6 x7 rank 141 Escambia 2002 6.50

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

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

I'm having issues of my compiler, and JIT execution, of LLVM IR being rather slow. It's accounting for the vast majority of my full compilation time.  I'm trying to figure out why this is happening, since it's becoming an impediment.  (Note: by slow I mean about 3s of time for only about 2K of my front-end code, 65K lines of LLVM-IR) Using valgrind I see some functions which seem

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 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

Hi, I am a total beginner with this whole thing so please have patience! I am trying to run an S-plus program with a certain line: spline(1:nrow(y), y[,1],n=100); This crashes with: Error: NAs in foreign function call (arg 8) Apparently, this is caused by the last command of spline: u <- seq(xmin, xmax, length.out = n) .C("spline_eval", z$method, length(u), x = u, y =

On Sat, Jun 01, 2013 at 06:45:48AM +0200, Duncan Sands wrote: > > These results are very disappointing, I was hoping to see a big improvement > somewhere instead of no real improvement anywhere (except for gas_dyn) or a > regression (eg: mdbx). I think LLVM now has a reasonable array of fast-math > optimizations. I will try to find time to poke at gas_dyn and induct: since >

Hello I?m need fitt growth curve with data length-age. I want to evaluate which is the function that best predicts my data, to do so I compare the Akaikes of different models. I'm now need to evaluate if changing the initial values changes the parameters and which do not allow to estimate the model. To do this I use the function nls(); and I randomize the initial values (real positive number).

[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

Hi, Could you share how you compile IR and which version of JIT you use (Orc, MCJIT)? Could it be that you are using interpreter instead of actual JIT? Cheers, Alex. > On 5. May 2018, at 08:04, edA-qa mort-ora-y via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > I'm having issues of my compiler, and JIT execution, of LLVM IR being > rather slow. It's accounting for

Hi Jack, thanks for splitting out what the effects of LLVM's / GCC's vectorizers is. On 01/06/13 21:34, Jack Howarth wrote: > On Sat, Jun 01, 2013 at 06:45:48AM +0200, Duncan Sands wrote: >> >> These results are very disappointing, I was hoping to see a big improvement >> somewhere instead of no real improvement anywhere (except for gas_dyn) or a >> regression

Hi Jack, On 29/05/13 22:04, Jack Howarth wrote: > On Wed, May 29, 2013 at 03:25:30PM +0200, Duncan Sands wrote: >> Hi Jack, I pulled the loop vectorizer and fast math changes into the 3.3 branch, >> so hopefully they will be part of 3.3 rc3 (and 3.3 final!). It would be great >> if you could redo the benchmarks rc3. >> > > Duncan, > As requested, appended

Dear R-helpers, I have two data frames, op and em4: > str(op) 'data.frame': 37 obs. of 5 variables: $ m : num 0.202 0.336 0.122 0.139 0.14 ... $ lln : num 0.798 0.643 0.863 0.835 0.823 ... $ rrn : num 0.789 0.702 0.894 0.895 0.923 ... $ asym2: num 0.177 0.304 0.108 0.187 0.274 ... $ asym3: num 0.0755 0.0975 0.0818 0.0651 0.13 ... > str(rownames(op)) chr

I have just started trying Opus with a view to using it in a project. I am interested in embedded hardware and tried it on the Raspberry Pi using the raspbian distro. The version of libopus in the repos is 0.9.14. I installed this and tried encoding 2 minutes of speech from a librevox recording. It managed this at a respectable pace for complexity 10: Skipping chunk of type "LIST",

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

Jack, Can you please file a bug report and attach the BC files for the major loops that we miss ? Thanks, Nadav On Jun 2, 2013, at 1:27, Duncan Sands <duncan.sands at gmail.com> wrote: > Hi Jack, thanks for splitting out what the effects of LLVM's / GCC's vectorizers > is. > > On 01/06/13 21:34, Jack Howarth wrote: >> On Sat, Jun 01, 2013 at 06:45:48AM +0200,

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.