similar to: function min does not return correct result if .Machine$integer.max (PR#8732)

Full_Name: Martin Schlather Version: 2.2.0 and alpha 2.3.0 (06/3/29) OS: Linux (x86_64 and Intel) Submission from: (NULL) (139.11.183.106) > min(.Machine$integer.max, 10^20) [1] 1e+20 > min(as.integer(.Machine$integer.max), 10^20) [1] 1e+20 but > min(.Machine$integer.max + 0, 10^20) [1] 2147483647 > min(as.integer(.Machine$integer.max - 1), 10^20) [1] 2147483646 >

Dear R-Developers, I think I found two bugs in max.col(). Ties between zeros are not broken, which might affect simulations. -Inf and Zero can be treated the same, which can give completely wrong results, e.g. when the second max is sought by replacing all maxs by -Inf. To fix max.col I do offer the C-code behind my function rowMax(), which also handles NAs and seems to be faster. However,

>>>>> Martin Maechler >>>>> on Fri, 11 Jan 2019 09:44:14 +0100 writes: >>>>> Michael Chirico >>>>> on Fri, 11 Jan 2019 14:36:17 +0800 writes: >> Identified as root cause of a bug in data.table: >> https://github.com/Rdatatable/data.table/issues/3267 >> On my machine, strtoi("", base =

>>>>> Michael Chirico >>>>> on Fri, 11 Jan 2019 14:36:17 +0800 writes: > Identified as root cause of a bug in data.table: > https://github.com/Rdatatable/data.table/issues/3267 > On my machine, strtoi("", base = 2L) produces NA_integer_ > (which seems consistent with ?strtoi: "Values which cannot > be

Thanks Martin. For what it's worth, this extremely representative, highly scientific Twitter poll suggests the Mac/Linux split is pretty stark (NA on Mac, 0 on Linux) https://twitter.com/michael_chirico/status/1083649190117306369?s=17 On Sat, Jan 12, 2019, 2:00 AM Martin Maechler <maechler at stat.math.ethz.ch wrote: > >>>>> Martin Maechler > >>>>>

This is a great example how you cannot figure it out after spending two hours troubleshooting, but a few minutes after you post to R-devel, it's just jumps to you (is there a word for this other than "impatient"?); Let me answer my own question. The discrepancy between my sum2() code and the internal code for base::sum() is that the latter uses LDOUBLE = long double (on some system

I'm observing that base::sum(x, na.rm=FALSE) for typeof(x) == "double" is much more time consuming when there are missing values versus when there are not. I'm observing this on both Window and Linux, but it's quite surprising to me. Currently, my main suspect is settings in on how R was built. The second suspect is my brain. I hope that someone can clarify the below

Looking for more ways to speed up R, I've found that large improvements are possible in the speed of "sum" and "prod" for long real vectors. Here is a little test with R version 2.11.1 on an Intel Linux system > a <- seq(0,1,length=1000) > system.time({for (i in 1:1000000) b <- sum(a)}) user system elapsed 4.800 0.010 4.817 > system.time({for (i

R Version 1.4.0 Patched (2002-01-23) Solaris 5.8 I just noticed that max(NULL) gives a strange result: > max(NULL) [1] -2147483647 Warning message: no finite arguments to min/max; returning extreme. in: max(..., na.rm = na.rm) I discovered this when I did something like max(object$element) for an incorrect element name. The warning message was helpful, but I was still surprised to

Hi the list, I am writing a R function that call a C function. The C function needs integers but I do not manage to give a NA integer as argument : --- C code --- void essai(int *t){ Rprintf("\nT0=%i T1=%i T2=%i T3=%i",t[0],t[1],t[2],t[3]); } --- R --- boub <- c(1,2,3,4) .C("pour",as.integer(boub),NAOK=TRUE) # T0=1 T1=2 T2=3 T3=4[[1]] # [1] 1 2 3 4 boub <-

Hi, Please see the email exchanges below. I am having trouble generating output that is large enough for our needs, specifically when using the GaussRF function. However, when I wrote Dr. Schlather (the author of the GaussRF function), he indicated that there is also a limit imposed by R itself. Is this something that we can overcome? Thank you very much for any assistance you may provde.

On 9/21/19 6:56 AM, Richard W.M. Jones wrote: > sscanf is sadly not safe (because it doesn't handle integer overflow > correctly), and strto*l functions are a pain to use correctly. > Therefore add some functions to hide the pain of parsing integers from > the command line. > > The simpler uses of sscanf and strto*l are replaced. There are still > a few where we are

I have observed the following differences in the use of min/max functions between R and Splus (4.5) R (0.64.1): min(c(NA,NA,NA),na.rm=T) returns the following Warning in min(..., na.rm = na.rm) : no finite arguments to min/max; returning extreme. [1] 2147483647 S-Plus 4.5( Win32 edition) min(c(NA,NA,NA),na.rm=T) returns [1] NA The S-PLUS behaviour seems to be the right one Thanks,

Full_Name: Nick Efthymiou Version: R1.5.0 and above OS: Red Hat Linux Submission from: (NULL) (162.93.14.73) With the introduction of the functions rowSums(), colSums(), rowMeans() and colMeans() in R1.5.0, function "SEXP do_colsum(SEXP call, SEXP op, SEXP args, SEXP rho)" was added to perform the fast summations. We have an excellent opportunity to improve the accuracy by

I'm building samba-3.2.0 on a Solaris 10 x64 box using the Sun Studio cc compiler. I'm running into a problem. I have a workaround. Let me know if I should post a bug report. A. The problem: $ ./configure --prefix=/usr/local/samba-3.2.0 --with-ads --with-pam --with-acl-support --with-shared-modules=idmap_ad --enable-socket-wrapper --enable-nss-wrapper

I found a bug in one of the fourteen speed patches I posted, namely in patch-vec-subset. I've fixed this (I now see one does need to duplicate index vectors sometimes, though one can avoid it most of the time). I also split this patch in two, since it really has two different and independent parts. The patch-vec-subset patch now has only some straightforward (locally-checkable) speedups for

Martin Maechler asked me to restate my problem. Compiling the file (slightly modified w.r.t. the formerly attached file) that can be found at http://www.geo.uni-bayreuth.de/~martin/filetransfer/xswms2d.Rd terminates with the error message ******* Syntax error: mismatched or missing brackets in /----- ..... \----- when compiled by R CMD Rdconv -t txt xswms2d.Rd However, the file does

Hi, I'm not sure this is a bug, so I thought I'd bounce it off the help group first. I had a dataset which I was subsetting, and occasionally I get an empty subset. If I don't check for emptiness and go straight to a which.min call on the subset, the program gets a big negative number back. One-line Example: > which.max(NULL) [1] -2147483647 This caused an indexing

I've noticed that the max.col function with the default "random" option often gives unexpected results. For instance, in this test, it seems clear what the answer should be: > # second col should always be max > x1 = cbind(1:10, 2:11, -Inf) > > # this works fine > max.col(x1, "first") [1] 2 2 2 2 2 2 2 2 2 2 > > # this gives random answers >

Full_Name: John Brzustowski Version: 2.8.1 OS: linux Submission from: (NULL) (67.71.250.146) When entering a debug()'ed function, the call printout is not limited by options()$deparse.max.lines as it is when one uses browser() or trace(). Should it be? If so, here's a patch: diff -cr R-2.8.1/src/library/base/man/options.Rd R-2.8.1-patched/src/library/base/man/options.Rd ***