similar to: Inconsistency: sort(NULL)/sort.int(NULL) does not throw an error, cf. order(NULL), sort.int(NULL, index.return=TRUE), ...

Does sort.int(c(2,NA,4), index.return=TRUE, na.last=NA, method="radix")$ix give the intended result, because I get: > sort.int(c(2,NA,4), index.return=TRUE, na.last=NA, method="radix") $x [1] 2 4 $ix [1] 1 3 With method="shell" and method="quick" in R devel, I get: > sort.int(c(2,NA,4), index.return=TRUE, na.last=NA, method="shell") $x

Hello, I am building R r55221 according to http://cran.r-project.org/doc/manuals/R-admin.html#Building-from-source After I have done "make all && make recommended", "make bitmapdll" returns the following: E:\sandbox\R-2.13.r55221\src\gnuwin32>make bitmapdll make[1]: Entering directory `/cygdrive/e/sandbox/R-2.13.r55221/src/gnuwin32/bitmap' make CC='gcc

>>>>> Hilmar Berger >>>>> on Wed, 4 Sep 2019 15:25:46 +0200 writes: > Dear all, > I just stumbled upon some behavior of the == operator which is at least > somewhat inconsistent. > R version 3.6.1 (2019-07-05) -- "Action of the Toes" > Copyright (C) 2019 The R Foundation for Statistical Computing > Platform:

Dear Martin, On 11/09/2019 09:56, Martin Maechler wrote: > > > I wonder if data.frame(<some non-empty data>) == NULL should also return > > a value instead of an error. R help reads: > > > "At least one of |x| and |y| must be an atomic vector, but > > if the other is a list R attempts to coerce it to the > > type of the atomic

Dear all, I just stumbled upon some behavior of the == operator which is at least somewhat inconsistent. R version 3.6.1 (2019-07-05) -- "Action of the Toes" Copyright (C) 2019 The R Foundation for Statistical Computing Platform: x86_64-w64-mingw32/x64 (64-bit) > list(a=1:3, b=LETTERS[1:3]) == NULL logical(0) > matrix(1:6, 2,3) == NULL logical(0) > data.frame(a=1:3,

Hi, if an atomic with colnames / rownames attribute is sorted, its names are not sorted in the appropriate way: R> a <- matrix(1:5, ncol=5) R> colnames(a) <- paste("V", 1:5, sep="") R> a V1 V2 V3 V4 V5 [1,] 1 2 3 4 5 R> sort(a, dec=TRUE) V1 V2 V3 V4 V5 [1,] 5 4 3 2 1 R> ?sort states that x is `a numeric or complex vector'

Dear R help group: I am attempting to produce a density plot from a list of 20000 values using the density.lf function and would appreciate any help, I hope I have done my homework reading the documentation but I still seem to be missing something basic. I have read the data as a table using read.table, with header=TRUE (I excluded 2000 values), when calling the objects it appears to be there and

In R-devel (svn 49628) and back to at least R 2.7.0 we get inconsistent results when attempting to attach attributes to a variable with the value NULL. If we use attributes<- it finishes but changes the value to list(). > a<-NULL > attributes(a)<-list(attr1="First attribute", attr2=2+2i) > a list() attr(,"attr1") [1] "First

The R help for cbind/rbind states: > For `cbind' (`rbind'), vectors of zero length are ignored unless > the result would have zero rows (columns), for S compatibility. > (Zero-extent matrices do not occur in S and are not ignored in R.) I presume this means the S language as defined in the Blue Book ("The ^New S Language", Becker Chambers & Wilks,

Another example where a data.frame is compared to (here non-null, non-empty) non-atomic values in Ops.data.frame, resulting in an error message: setClass("FOOCLASS2", ???????? slots = c(M="matrix") ) ma = new("FOOCLASS2", M=matrix(rnorm(300), 30,10)) > isS4(ma) [1] TRUE > ma == data.frame(a=1:3) Error in eval(f) : dims [product 1] do not match the length

>>>>> Martin Maechler >>>>> on Wed, 18 Sep 2019 10:35:42 +0200 writes: >>>>> Hilmar Berger >>>>> on Sat, 14 Sep 2019 13:31:27 +0200 writes: >> Dear all, >> I did some more tests regarding the == operator in Ops.data.frame (see >> below).? All tests done in R 3.6.1

Dear all, Trying to solve a problem I had (see thread "putting NAs at the end" ) I've noticed a difference in system time requirements between using apply and sort (or order) to order each row or column of a matrix compared to a vectorized function I wrote. Using apply is much faster when the number of loops (number of rows or columns to order) is low BUT much slower when number of

R-Version: 1.7.1 (2003-06-16) OS: Debian/GNU Linux cbind and rbind handle NULL parameters inconsistently. Consider: > cbind() NULL > cbind(NULL) NULL And: > cbind(diag(x = 1, 1, 1)) [,1] [1,] 1 > cbind(NULL, diag(x = 1, 1, 1)) [,1] [1,] 1 These seem to indicate that NULL parameters will be ignored in any call to cbind and rbind. However: >

The NEWS file for R-devel (as of 2018-11-28 r75702) says ? order(...., decreasing=c(TRUE,FALSE)) could fail in some cases. Reported from StackOverflow via Karl Nordstr?m. However, either I don't understand the meaning of decreasing=c(TRUE,FALSE) or there are still problems. I thought order(x,y,decreasing=c(TRUE,FALSE) meant to return indices, i, such that x[i] was non-increasing and

On 18.08.2017 14:55, Webert de Souza Lima wrote: > Hello, > > The following errors are constantly popping up for 2 accounts. I can't get > it fixed, > I did doveadm backup to another account, the same happens in the new > account. > I did doveadm force-resync, the problem persists. > > I'm using dovecot 2.2. > > 2017-08-18T11:46:12.472821881Z Aug 18

Dear all, I did some more tests regarding the == operator in Ops.data.frame (see below).? All tests done in R 3.6.1 (x86_64-w64-mingw32). I find that errors are thrown also when comparing a zero length data.frame to atomic objects with length>0 which should be a valid case according to the documentation. This can be traced to a check in the last line of Ops.data.frame which tests for the

On Fri, Aug 18, 2017 at 9:03 AM, Aki Tuomi <aki.tuomi at dovecot.fi> wrote: > This is fixed in next release (2.2.32) with > https://github.com/dovecot/core/commit/c8be394 > > Aki Tuomi > As this is still a release candidate, I'm thinking of running an isolated instance of this version, and do doveadm force-resync just to fix just this user's mailbox. What do you

On 18 Aug 2017, at 16.43, Webert de Souza Lima <webert.boss at gmail.com> wrote: > > On Fri, Aug 18, 2017 at 9:03 AM, Aki Tuomi <aki.tuomi at dovecot.fi> wrote: > >> This is fixed in next release (2.2.32) with >> https://github.com/dovecot/core/commit/c8be394 >> >> Aki Tuomi >> > > As this is still a release candidate, I'm thinking

After a (power)crash two accounts have been corrupted. I tried to rescue things by running force-resync multiple times, but that didn't work out. Searching the archives, I found a recent suggestion (by Timo) to delete the index files, but I'm not sure which files to delete and what the consequences will be. When I deleted ``storage/dovecot.map.index'' in an unimportant account

In S, NULL and list() are not the same. In R they are (I think). --------------------------------------------------- At least, is.list(NULL) #-> 'F' in S; 'TRUE' in R Yes: I had an instance where this broke correct S code: match(c("xlab","ylab"), names(list(...))) when '...' is empty, gives an error in R, but gives c(NA,NA) in S.