search for: roundoff

...e0] or nearby, I do: cerr << "some stuff" << endl; mat3 = matmult(mat1,mat2); I get a difference of the order 1.0e-15 depending on whether the cerr line does or does not end in "endl" as shown. I am imagining that there is some "randomness" in the roundoff that depends on the I/O situation. Is this credible? Any other suggestions? Thanks for your help, Mike.

Dear R users, i try to integrate lgamma from 0 to Inf. But here i get the message "roundoff error is detected in the extrapolation table", if i use 1.0e120 instead of Inf the computation works, but this is against the suggestion of integrates help information to use Inf explicitly. Using stirlings approximation doesnt bring the solution too. ## Stirlings approximation lgammaApprox &...

...subdivisions = 300, rel.tol = tol)$value > Fy <- Vectorize(fy) > xa <- -1; xb <- 1 > Q <- integrate(Fy, xa, xb, subdivisions = 300, rel.tol = tol)$value Error in integrate(Fy, xa, xb, subdivisions = 300, rel.tol = tol) : roundoff error was detected Obviously, this realizes a double integration, split up into two 1-dimensional integrations, and the result shall be pi/4. I wonder what a 'roundoff error' means in this situation. In my package, this test worked well, w/o error or warnings, since July 2011, on Windows,...

....tol), as.double(rel.tol), limit = limit, PACKAGE = "base") } res <- wk[c("value", "abs.error", "subdivisions")] res$message <- switch(wk$ierr + 1, "OK", "maximum number of subdivisions reached", "roundoff error was detected", "extremely bad integrand behaviour", "roundoff error is detected in the extrapolation table", "the integral is probably divergent", "the input is invalid") if (wk$ierr == 6 || (wk$ierr > 0 && stop.on.er...

Mark Borgerding wrote: > Each math operation introduces some error. So the fewer operations > required, the fewer roundoff errors occur. This leads to a happy > correlation between efficiency and accuracy. The more important problem is addition of numbers that differ in magnitude. Roundoff error is soooo small compared to that ;) <p>Segher --- >8 ---- List archives: http://www.xiph.org/archives/ Ogg p...

...have tried: x<-as.integer(x*100+0.5)/100 and x<-floor(x*100+0.5)/100 However, some values of x cause problems e.g x<-floor(4.145*100+0.5)/100 4.14 I have tried breaking it down into steps and force the results to 10 significant figures in the following function, which seems to work roundoff<-function(x){ a<-signif(x*100+0.5,digits=10) roundoff<-floor(a)/100 roundoff } Is there a more sensible way of do this for all numbers? Thanks Mike [[alternate HTML version deleted]]

Thanks guys, I guess I should have referred to FAQ 7.31 (which I am indeed very familiar with) to avoid misunderstanding. I have always used dput() to clarify 7.31-type issues. The description in ?dput implies [to me at any rate] that there will be no floating-point roundoff in its output. I hadn't realised that 'deparsing' as discussed in dput.Rd includes precision roundoff issues. I guess the question I should have asked is close to Ben's: "How to force dput() to return an exact representation of a floating point number?". Duncan's re...

...Q 7.31 > > (which I am indeed very familiar with) to avoid > > misunderstanding. I have always used dput() to clarify > > 7.31-type issues. > > > The description in ?dput implies [to me at any rate] that > > there will be no floating-point roundoff in its output. I > > hadn't realised that 'deparsing' as discussed in dput.Rd > > includes precision roundoff issues. > > > I guess the question I should have asked is close to > > Ben's: "How to force dput() to return an exact &...

...hts = n) you get a different result than if you perform the logit transformation manually on p and perform output <- lm(logit(p) ~ x, weights = w), where logit(p) is either obtained from R with qlogis(p) or from a manual computation of ln(p/1-p). The difference seems to me to be too large to be roundoff error. The only thing I can guess is that the application of the weights in glm is different than in a manual computation. Can anyone explain the difference in results? Daniel Pick Principal Daniel Pick Scientific Software Consulting San Diego, CA E-Mail: mth_man at yahoo.com

> I had the idea of implementing a lot of the operations in FFTs. ( for > example, it is possible to do auto-correlation and FIR filtering using > FFTs.) There are two advantages to this. > 1. It's almost always faster > 2. By swapping fft implementations, it could be easy to recompile for > fixed or floating point versions. No. FFT's require higher precision than

...increase the number of subdivisions (as this is a parameter in integrate(). Thus I raised it from 100 to 1000 (and then to 10000). A. Does this makes the error produced higher or does it only stress the computer? B. When the number was raised to 10.000 I started getting the error message "roundoff error was detected" What do you think I should do to solve that? I would like to thank u in advance for your help Best Regards Alex

Hi I have a problem with this error, I have searched the archives and found previous discussion about this, can I cannot understand how the explanations apply to what I am trying to do. I am trying to do Log_rank Survival analysis, I have included tables and str command, is it a factor/integer problem? If so how do I correct this, as all my attempt to recode the data have failed. >

Hi, All: Is there a simple way to detect complex conjugates in the roots returned by 'polyroot'? The obvious comparison of each root with the complex conjugate of the next sometimes produces roundoff error, and I don't know how to bound its magnitude: (tst <- polyroot(c(1, -.6, .4))) tst[-1]-Conj(tst[-2]) [1] 3.108624e-15+2.22045e-16i abs(tst[-1]-Conj(tst[-2]))/abs(tst[-1]) 1.971076e-15 .Machine$double.neg.eps 1.110223e-16 Testing (abs(tst[-1]-Conj(tst[-2]))/abs(tst[-1]) <...

Hi; I am having problems inverting matrices using the function solve() For example R can not invert the following matrix [,1] [,2] [,3] [,4] [,5] [1,] 25 500 11250 275000 7.106250e+06 [2,] 500 11250 275000 7106250 1.906250e+08

...the the zeros or not ) depends on the size of fxdata ? I had the following line for doing the above : fxdata<-fxdata[( fxdata[,"bid"] > 0.0 ) & ( fxdata[,"ask"] > 0.0 ),] But I am thinking that there maybe there is a problem with this type of approach because of roundoff error ? Does someone know of a more stable way of checking this condition ? There is no need to cut and paste the code above or below because the above line above, for certain sizes of temp, does seem to work. But, then when temp gets too large, it seems to only get some of the zeros ? I realize t...

...guess I should have referred to FAQ 7.31 > (which I am indeed very familiar with) to avoid > misunderstanding. I have always used dput() to clarify > 7.31-type issues. > The description in ?dput implies [to me at any rate] that > there will be no floating-point roundoff in its output. I > hadn't realised that 'deparsing' as discussed in dput.Rd > includes precision roundoff issues. > I guess the question I should have asked is close to > Ben's: "How to force dput() to return an exact > representation of a f...

...; (which I am indeed very familiar with) to avoid >> > misunderstanding. I have always used dput() to clarify >> > 7.31-type issues. >> >> > The description in ?dput implies [to me at any rate] that >> > there will be no floating-point roundoff in its output. I >> > hadn't realised that 'deparsing' as discussed in dput.Rd >> > includes precision roundoff issues. >> >> > I guess the question I should have asked is close to >> > Ben's: "How to force dput()...

I am experiencing strange (to me) output when trying to do simple calculations. Expressions that should equal zero yield non-zero values. Examples: > a <- 4.1-3.1 > b <- 5.1-4.1 > a-b [1] -4.440892e-16 > (4.1-3.1)-(5.1-4.1) [1] -4.440892e-16 When this last expression is expanded, I get the right answer: > 4.1-3.1-5.1+4.1 [1] 0 I am using the binary packaged version

Hi, Today I was flabbergasted to see something that looks like a rounding error in the very basic seq function in R. > a = seq(0.1,0.9,by=0.1) > a [1] 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 > a[1] == 0.1 [1] TRUE > a[2] == 0.2 [1] TRUE > a[3] == 0.3 [1] FALSE It turns out that the alternative > a = (1:9)/10 works just fine. Are there any good guides out there on how to deal

There seems to be a bug with var() when the argument is a vector with exactly three values of 1e30 (or close to this value). This does not happen with twice, four (or more) times this value, or another value. > var(rep(1e30, 3)) [1] 2.971056e+28 > var(rep(1.2e30, 3)) [1] 2.971056e+28 > var(rep(0.9e30, 3)) [1] 2.971056e+28 > var(rep(0.8e30, 3)) [1] 0 > var(rep(1e29, 3)) [1] 0 >