similar to: -1.1 - 0.1 + 1.2 is NOT null! Why?

Dear All, I am running a r code on 32bit win, involving absolutely small numbers. Although I tried sth like the ratio of numers like 10^(-100) and did not have issue to get the correct answer, but still a little concerned about it. Could anyone give some suggestion or have any experience? Best wishes, Jie [[alternative HTML version deleted]]

Dear community I have a dataframe and want to split it into a learn and a test partition. However the learnset should be balanced, i.e. each class should have the same number of cases. I tried and searched a lot, without success so far. Maybe you can help? Some example code *# generate example data df <- data.frame(class = as.factor(sample(1:3, 20, replace = T)), var1 = rnorm(20,3), var2 =

>> I have come across your reported log1p error (#2837) on a NetBSD (1.6W) >> system. I've just made further experiments on the deficient log1p() function on OpenBSD 3.2 and NetBSD 1.6 with this test program: % cat bug-log1p.c #include <stdio.h> #include <stdlib.h> #include <math.h> int main(int argc, char* argv[]) { int k; double x; for (k = 0; k

Full_Name: Vlad Stolin Version: R 2.0.0 OS: Windows 2000 Submission from: (NULL) (204.128.232.211) When generating the sequence using seq() function with non-integer numbers result is somewhat unpredictable. Example: > v1<-seq(1.60,1.90,.05) > v2<-c(1.60,1.65,1.70,1.75,1.80,1.85,1.90) > v1-v2 [1] 0.000000e+00 2.220446e-16 2.220446e-16 0.000000e+00 0.000000e+00 0.000000e+00

I think what's been missed is that zapsmall works relative to the absolute largest value in the vector. Hence if there's only one item in the vector, it is the largest, so its not zapped. The function's raison d'etre isn't to replace absolutely small values, but small values relative to the largest. Hence a vector of similar tiny values doesn't get zapped. Maybe the line

I was quite suprised to discover that applying `zapsmall` to a scalar value has no apparent effect. For example: > y <- 2.220446e-16 > zapsmall(y,) [1] 2.2204e-16 I was expecting zapsmall(x)` to act like > round(y, digits=getOption('digits')) [1] 0 Looking at the current source code, indicates that `zapsmall` is expecting a vector: zapsmall <- function (x, digits =

Zapping a vector of small numbers to zero would cause problems when printing the results of summary(). For example, if zapsmall(c(2.220446e-16, ..., 2.220446e-16)) == c(0, ..., 0) then print(summary(2.220446e-16), digits = 7) would print Min. 1st Qu. Median Mean 3rd Qu. Max. 0 0 0 0 0 0 The same problem can also appear when

Isn?t that the correct outcome? The user can change the number of digits if they want to see small values? -- Change your thoughts and you change the world. --Dr. Norman Vincent Peale > On Dec 17, 2023, at 12:11?AM, Steve Martin <stevemartin041 at gmail.com> wrote: > > ?Zapping a vector of small numbers to zero would cause problems when > printing the results of summary().

I have found that the polyroot() function in R-1.1.1(both solaris and Win32 version) gives totally incorrect result. Here is the offending code: # Polyroot bug report: # from R-1.1.1 > sort(abs(polyroot(c(1, -2,1,0,0,0,0,0,0,0,0,0,-2,5,-2,0,0,0,0,0,0,0,0,0,1,-2,1)))) [1] 0.8758259 0.9486499 0.9731015 1.5419189 1.7466214 1.7535362 1.7589484 [8] 2.0216317 2.4421509 2.5098488 2.6615572

Full_Name: Chanseok Park Version: R 2.2.1 OS: RedHat EL4 Submission from: (NULL) (130.127.112.89) pbinom(any negative value, size, prob) should be zero. But I got the following results. I mean, if a negative value is close to zero, then pbinom() calculate pbinom(0, size, prob). dbinom() also behaves similarly. > pbinom( -2.220446e-22, 3,.1) [1] 0.729 > pbinom( -2.220446e-8, 3,.1)

Le 17/12/2023 ? 18:26, Barry Rowlingson a ?crit?: > I think what's been missed is that zapsmall works relative to the absolute > largest value in the vector. Hence if there's only one > item in the vector, it is the largest, so its not zapped. The function's > raison d'etre isn't to replace absolutely small values, > but small values relative to the largest.

Dear all, I a bit unsure, whether this qualifies as a bug, but it is definitly a strange behaviour. That why I wanted to discuss it. With the following function, I want to test for evenly space numbers, starting from anywhere. .is_continous_evenly_spaced <- function(n){ if(length(n) < 2) return(FALSE) n <- n[order(n)] n <- n - min(n) step <- n[2] - n[1] test <-

>>>>> Serguei Sokol via R-devel >>>>> on Mon, 18 Dec 2023 10:29:02 +0100 writes: > Le 17/12/2023 ? 18:26, Barry Rowlingson a ?crit?: >> I think what's been missed is that zapsmall works relative to the absolute >> largest value in the vector. Hence if there's only one >> item in the vector, it is the largest, so its

Le 18/12/2023 ? 11:24, Martin Maechler a ?crit?: >>>>>> Serguei Sokol via R-devel >>>>>> on Mon, 18 Dec 2023 10:29:02 +0100 writes: > > Le 17/12/2023 ? 18:26, Barry Rowlingson a ?crit?: > >> I think what's been missed is that zapsmall works relative to the absolute > >> largest value in the vector. Hence if

Agreed that's it's rounding error, and all.equal would be the way to go. I wouldn't call it a bug, it's simply part of working with floating point numbers, any language has the same issue. And while we're at it, I think the function can be a lot shorter: .is_continous_evenly_spaced <- function(n){ length(n)>1 && isTRUE(all.equal(n[order(n)], seq(from=min(n),

I just tried the rsync version of R-1.1.0 on one of my alphas: It compiles without problems (gcc/g77 2.95.2, system is DU4.0E) but make check stops in base-Ex.R at > X <- cbind(1, 1:7) > str(s <- svd(X)); D <- diag(s$d) List of 3 $ d: num [1:2] 12.07 1.16 $ u: num [1:7, 1:2] -0.0976 -0.1788 -0.2601 -0.3413 -0.4225 ... $ v: num [1:2, 1:2] -0.198 -0.980 -0.980 0.198 >

I noticed the following peculiarity with `serialize()' when `ascii = TRUE' is used. In today's (svn r37299) R-devel, I get > set.seed(10) > x <- rnorm(10) > > a <- serialize(x, con = NULL, ascii = TRUE) > b <- unserialize(a) > > identical(x, b) ## FALSE [1] FALSE > x - b [1] -3.469447e-18 2.775558e-17 -4.440892e-16 0.000000e+00

El vie., 31 ago. 2018 a las 16:00, Mark van der Loo (<mark.vanderloo at gmail.com>) escribi?: > > how about > > is_evenly_spaced <- function(x,...) all.equal(diff(sort(x)),...) This doesn't work, because 1. all.equal does *not* return FALSE. Use of isTRUE or identical(., TRUE) is required if you want a boolean. 2. all.equal compares two objects, not elements in a vector.

Hello All. I am running R 2.0.0 with a Win XP operating system. The same problem occured with R 1.9.1 but not with R.1.3.1 on a Win NT computer. My request is about the following problem with the sort function: The vector price is a vector of 789 asset prices of the following form, > mode(price) [1] "numeric" > price[1:10] [1] 1.1315 1.1314 1.1313 1.1314 1.1315 1.1316 1.1315

Hello, everyone, There's a problem about zero in R and I really need your help. I have a vector shown as x=c(0.1819711,0.4811463,0.1935151,0.1433675), The sum of this vector is shown as 1 in R, but when I type 1-sum(x), the value is not zero, but -2.220446e-16. I can accept that this value is quite small and could be seen as zero, but there would be a problem when it's not really