search for: 1e9

...$> R --vanilla x <- c(0L, -2e9:2e9) # > Segmentation fault Tried to reproduce on Linux but the above worked as expected. Not an issue merely with the length of the vector; for example, x <- rep_len(1:10, 1e10) works, though the altrep vector must be long to reproduce: x <- c(0L, -1e9:1e9) #ok Segmentation faults occur with the following too: x <- (-2e9:2e9) + 1L

...ault >> Tried to reproduce on Linux but the above worked as expected. Not an >> issue merely with the length of the vector; for example, x <- >> rep_len(1:10, 1e10) works, though the altrep vector must be long to >> reproduce: >> x <- c(0L, -1e9:1e9) #ok >> Segmentation faults occur with the following too: >> x <- (-2e9:2e9) + 1L > Your operation would "need" (not in theory, but in practice) > to go from altrep to regular vectors. > I guess the segfault occurs because of something l...

...Linux but the above worked as expected. Not an >> >> issue merely with the length of the vector; for example, x <- >> >> rep_len(1:10, 1e10) works, though the altrep vector must be long to >> >> reproduce: >> >> >> x <- c(0L, -1e9:1e9) #ok >> >> >> Segmentation faults occur with the following too: >> >> >> x <- (-2e9:2e9) + 1L >> >> > Your operation would "need" (not in theory, but in practice) >> > to go from altrep to regular vectors. &gt...

See https://stat.ethz.ch/pipermail/r-devel/2017-August/074746.html for the origin of the example here. That pretty(c(-1,1)*1e300, n = 1e9, min.n = 1) gave 20 intervals, far from 1e9, but pretty(c(-1,1)*1e300, n = 1e6, min.n = 1) gave 1000000 intervals (on a machine), made me trace through the code to function 'R_pretty' in https://svn.r-project.org/R/trunk/src/appl/pretty.c . *lo is -1e300, *up is 1e300. cell = fmax2(fabs(*l...

...t the above worked as expected. Not an >> >> issue merely with the length of the vector; for example, x <- >> >> rep_len(1:10, 1e10) works, though the altrep vector must be long to >> >> reproduce: >> >> >> x <- c(0L, -1e9:1e9) #ok >> >> >> Segmentation faults occur with the following too: >> >> >> x <- (-2e9:2e9) + 1L >> >> > Your operation would "need" (not in theory, but in practice) >> > to go from altrep to r...

...> Segmentation fault > Tried to reproduce on Linux but the above worked as expected. Not an > issue merely with the length of the vector; for example, x <- > rep_len(1:10, 1e10) works, though the altrep vector must be long to > reproduce: > x <- c(0L, -1e9:1e9) #ok > Segmentation faults occur with the following too: > x <- (-2e9:2e9) + 1L Your operation would "need" (not in theory, but in practice) to go from altrep to regular vectors. I guess the segfault occurs because of something like this : R asks Windows to hand...

Examples similar to pretty(c(-1,1)*1e300, n = 1e9, min.n = 1) with smaller 'n': pretty(c(-1,1)*1e304, n = 1e5, min.n = 1) pretty(c(-1,1)*1e306, n = 1e3, min.n = 1) A report on 'pretty' when working with integers, similar to what led to change of 'seq' fuzz, is https://bugs.r-project.org/bugzilla3/show_bug.cgi?id=15137 ---...

...to reproduce on Linux but the above worked as expected. Not an > >> issue merely with the length of the vector; for example, x <- > >> rep_len(1:10, 1e10) works, though the altrep vector must be long to > >> reproduce: > > >> x <- c(0L, -1e9:1e9) #ok > > >> Segmentation faults occur with the following too: > > >> x <- (-2e9:2e9) + 1L > > > Your operation would "need" (not in theory, but in practice) > > to go from altrep to regular vectors. > > I guess the s...

...ried to reproduce on Linux but the above worked as expected. Not an > >> issue merely with the length of the vector; for example, x <- > >> rep_len(1:10, 1e10) works, though the altrep vector must be long to > >> reproduce: > > >> x <- c(0L, -1e9:1e9) #ok > > >> Segmentation faults occur with the following too: > > >> x <- (-2e9:2e9) + 1L > > > Your operation would "need" (not in theory, but in practice) > > to go from altrep to regular vectors. > > I guess the segfau...

...I had my R processes killed > more than once (and much worse also other processes so that we had to > reboot a server, essentially). I found that setting RLIMIT_AS [1] works very well on Linux. But this requires that you cap memory to some fixed value. > library(RAppArmor) > rlimit_as(1e9) > rnorm(1e9) Error: cannot allocate vector of size 7.5 Gb The RAppArmor package has many other utilities to protect your server such from a mis-behaving process such as limiting cpu time (RLIMIT_CPU), fork bombs (RLIMIT_NPROC) and file sizes (RLIMIT_FSIZE). [1] http://linux.die.net/man/2/getr...

...ed as expected. Not an > >> >> issue merely with the length of the vector; for example, x <- > >> >> rep_len(1:10, 1e10) works, though the altrep vector must be long to > >> >> reproduce: > >> > >> >> x <- c(0L, -1e9:1e9) #ok > >> > >> >> Segmentation faults occur with the following too: > >> > >> >> x <- (-2e9:2e9) + 1L > >> > >> > Your operation would "need" (not in theory, but in practice) > >> > to go...

...warnings as errors anyway) but for the sake of other useRs who may get bitten, perhaps we should be more explicit that backwards-compatibility won't be preserved under certain use patterns, for example: # works (with warning) in R 3.6.2 but fails (with error) in R-devel: vapply(list(1e9, 1e10), ?????? function(lambda) { ????????? rpois(1L, lambda) ?????? }, ?????? FUN.VALUE = integer(1L) ?????? ) # in R-devel, a little extra work to achieve a warning as before: vapply(list(1e9, 1e10), ?????? function(lambda) { ????????? tmp <- rpois(1...

Hi I have a source file in Splus that fails in R as I am using the Splus function compare(). compare( ii * 1e9,f ) where ii is a single variable and f is a vector of length 146 R returns with no function error Can anyone inform me how I can do this in R thanks in advance Bob Kelly [[alternative HTML version deleted]]

...an >>>> >> issue merely with the length of the vector; for example, x <- >>>> >> rep_len(1:10, 1e10) works, though the altrep vector must be long to >>>> >> reproduce: >>>> >>>> >> x <- c(0L, -1e9:1e9) #ok >>>> >>>> >> Segmentation faults occur with the following too: >>>> >>>> >> x <- (-2e9:2e9) + 1L >>>> >>>> > Your operation would "need" (not in theory, but in practice) >&gt...

...Anggono Suharto Anggono via R-devel <r-devel at r-project.org> >>>>> on Fri, 11 Aug 2017 17:11:06 +0000 writes: > See https://stat.ethz.ch/pipermail/r-devel/2017-August/074746.html for the origin of the example here. > That > pretty(c(-1,1)*1e300, n = 1e9, min.n = 1) gave 20 intervals, far from 1e9, but > pretty(c(-1,1)*1e300, n = 1e6, min.n = 1) gave 1000000 intervals > (on a machine), made me trace through the code to function 'R_pretty' in https://svn.r-project.org/R/trunk/src/appl/pretty.c . thank you. > *lo is -1e...

...ll "report the memory size", but is this the available memory, the total, or the amount in use? If it is the total, how is it different from memory.size(max=TRUE)? On my system the result of the three relevant memory functions are as follows: > MemSizeinGB=(memory.limit(size=NA))/1E9 > MaxMemGB=(memory.size(max=T))/1E9 > MemInUseGB=(memory.size(max=F))/1E9 > MemSizeinGB [1] 4.246733 > MaxMemGB [1] 1.567990 > MemInUseGB [1] 0.7674916 3)I have used the --max-mem-size option in the icon properties, shortcut tab, target field after the pathname of the executable, a...

...IsNaN could be improved when applied on a vector where we could take out small part of their logic, run it once, and then reuse inside the loop. I setup tiny plain-C experiment. Taking R_IsNA, R_IsNaN from R's arithmetic.c, and building R_vIsNA and R_vIsNaN accordingly. For double input of size 1e9 (having some NA and NaN) I observed following timings: R_IsNA 6.729s R_vIsNA 4.386s R_IsNaN 6.874s R_vIsNaN 4.479s ISNAN 4.392s It looks like R_vIsN(A|aN) are close to ISNAN (which just wraps to math.h::isnan). Should I follow up with a patch? The experiment is a single nan.c file...

...ct noticed by Bill that both as.Date() and format.Date() should probably be tweaked such as to signal warnings (e.g. on integer overflow for too large numbers). ## ------------------------------------------------------------------------- xDates <- lapply(c(-Inf, Inf, NA, NaN, 1e9, 4e9, 1e100, .Machine$double.xmax), as.Date, origin = "2000-01-01") str(xDates) # --> first 4 *all* show as NA sapply(xDates, is.na) # the two +-Inf are not NA (f.D <- sapply(xDates, format))# 1..4: NA, then "negative" but all the same (?!) stopifnot(is.n...

...gt;> more than once (and much worse also other processes so that we had to >> reboot a server, essentially). > I found that setting RLIMIT_AS [1] works very well on Linux. But this > requires that you cap memory to some fixed value. > >> library(RAppArmor) >> rlimit_as(1e9) >> rnorm(1e9) > Error: cannot allocate vector of size 7.5 Gb > > The RAppArmor package has many other utilities to protect your server > such from a mis-behaving process such as limiting cpu time > (RLIMIT_CPU), fork bombs (RLIMIT_NPROC) and file sizes (RLIMIT_FSIZE). > &gt...

...(_n)[0]; SEXP result = PROTECT(Rf_allocVector(INTSXP, n)); INTEGER_GET_REGION(_x, i, n, INTEGER(result)); UNPROTECT(1); return result; } For "shorter" vectors, the result is as expected: > dyn.load("altrep_int_region.so") > .Call("integer_get_region", 1:1e9, 0L, 10L) [1] 1 2 3 4 5 6 7 8 9 10 But not for "longer" vectors: > .Call("integer_get_region", 1:1e10, 0L, 10L) [1] 0 1072693248 0 1073741824 0 1074266112 [7] 0 1074790400 0 1075052544 Am I doing something wrong or...