similar to: is.vector(as.vector(x, m), m) not always TRUE

Hi, In the man page for is.unsorted(): Value: A length-one logical value. All objects of length 0 or 1 are sorted: the result will be ?NA? for objects of length 2 or more except for atomic vectors and objects with a class (where the ?>=? or ?>? method is used to compare ?x[i]? with ?x[i-1]? for ?i? in ?2:length(x)?). This contains many incorrect

Hi, Note sure why but subsetting by name is *very* slow when the character vector used as subscript contains a lot of "invalid" names: x <- c(A=10L, B=20L, C=30L) subscript <- c(LETTERS[1:3], sprintf("ID%05d", 1:150000)) > system.time(y1 <- x[subscript]) user system elapsed 111.991 0.000 112.230 Since subsetting by name is basically

Hi, I get an "internal error" when calling seek() twice on a gzfile connection. Create a gzip file: bigraw <- sample(charToRaw("abcdef"), 30000000, replace=TRUE) save(bigraw, file="bigraw.rda") Open it: con <- gzfile("bigraw.rda", "rb") Then: > seek(con, where=1) [1] 0 > seek(con, where=24980000) [1] 1

Hi, I'm running into more issues when reading data from a gzfile connection. If I read the data sequentially with successive calls to readBin(), the data I get looks ok. But if I call seek() between the successive calls to readBin(), I get corrupted data. Here is a (hopefully) reproducible example. See my sessionInfo() at the end (I'm not on Windows, where, according to the man page,

Hi, I noticed that when using print( , right=TRUE) on a character matrix with no colnames, the col numbers get displayed on the left of each column: > m <- matrix(rep(c("XXXXXX", "XXXX"), 6), ncol=3) > print(m, right=FALSE) [,1] [,2] [,3] [1,] "XXXXXX" "XXXXXX" "XXXXXX" [2,] "XXXX" "XXXX"

Hi, When 'x' is a vector of doubles, it's not clear how 'factor(x)' compares its values in order to determine the levels. For example, here all the values in 'x' are "conceptually" the same: x <- c(11/3, 2/3 + 4/3 + 5/3, 50 + 11/3 - 50, 7.00001 - 1000003/300000) However, due to machine rounding errors, they are not

I just meant that the minimal contract for as.list() appears to be that it returns a VECSXP. To the user, we might say that is.list() will always return TRUE. I'm not sure we can expect consistency across methods beyond that, nor is it feasible at this point to match the semantics of the methods package. It deals in "class space" while as.list() deals in "typeof() space".

>>>>> Michael Lawrence <lawrence.michael at gene.com> >>>>> on Tue, 30 Jan 2018 15:57:42 -0800 writes: > I just meant that the minimal contract for as.list() appears to be that it > returns a VECSXP. To the user, we might say that is.list() will always > return TRUE. Indeed. I also agree with Herv'e that the user level

Hi, The trick used by duplicated.data.frame() is to transform the supplied data.frame into a character vector by pasting together the columns using "\r" as separator. But no precautions are taken to deal with "\r" in the supplied data.frame. As a consequence it's easy to imagine situations where duplicated.data.frame() returns an incorrect answer: > df <-

On Sat, Mar 19, 2016 at 4:29 AM, Herv? Pag?s <hpages at fredhutch.org> wrote: > On 03/19/2016 01:22 AM, Michael Lawrence wrote: > >> >> >> On Sat, Mar 19, 2016 at 12:10 AM, Herv? Pag?s <hpages at fredhutch.org >> <mailto:hpages at fredhutch.org>> wrote: >> >> On 03/18/2016 03:28 PM, Michael Lawrence wrote: >> >> >>

Maybe behavior of 'as.list' in R is not inherited from S? - From https://bugs.r-project.org/bugzilla3/show_bug.cgi?id=78 , in "the prototype" (S), 'as.list' on a data frame gave a list, not a data frame as given by the default 'as.list' in R. That led to introduction of 'as.list.data.frame'. - From

Hi, Here is a problem we see with the Mac and Windows binaries of rJava (0.9-3) currently available on CRAN for R-devel (i.e. under bin/macosx/leopard/contrib/2.16/ and bin/windows/contrib/2.16/): > library(rJava) > .jinit("gaggle/inst/jars/gaggleRShell.jar") Error in .Call("R_do_new_object", ClassDef, PACKAGE = "base") :

Hi, relist() is broken when the skeleton is a list with empty list elements: > x <- list(1:3, integer(0), 11:14) > relist(unlist(x), x) [[1]] [1] 1 2 3 [[2]] [1] 11 3 [[3]] [1] 11 12 13 14 Hard to believe that such a bug has been around for 6 years (i.e. since the introduction of relist()) without ever being noticed. Cheers, H. > sessionInfo() R

On 01/30/2018 02:50 PM, Michael Lawrence wrote: > by() does not always return a list. In Gabe's example, it returns an > integer, thus it is coerced to a list. as.list() means that it should be > a VECSXP, not necessarily with "list" in the class attribute. The documentation is not particularly clear about what as.list() means for list derivatives. IMO clarifications

On Sat, Mar 19, 2016 at 12:10 AM, Herv? Pag?s <hpages at fredhutch.org> wrote: > On 03/18/2016 03:28 PM, Michael Lawrence wrote: > >> >> On Fri, Mar 18, 2016 at 2:53 PM, Herv? Pag?s <hpages at fredhutch.org >> <mailto:hpages at fredhutch.org>> wrote: >> >> Hi, >> >> Short story >> ----------- >> >>

On Thu, Feb 1, 2018 at 12:14 AM, Martin Maechler <maechler at stat.math.ethz.ch> wrote: >>>>>> Michael Lawrence <lawrence.michael at gene.com> >>>>>> on Tue, 30 Jan 2018 15:57:42 -0800 writes: > > > I just meant that the minimal contract for as.list() appears to be that it > > returns a VECSXP. To the user, we might say

Hi Gabe, Interestingly the behavior of as.list() on by objects seem to depend on the object itself: > b1 <- by(1:2, 1:2, identity) > class(as.list(b1)) [1] "list" > b2 <- by(warpbreaks[, 1:2], warpbreaks[,"tension"], summary) > class(as.list(b2)) [1] "by" This is with R 3.4.3 and R devel (2017-12-11 r73889). H. On 01/30/2018 02:33 PM,

Hi, I'm running into a case where byte-compilation changes the semantic of a function. This is with R 3.4.0: foo <- function(x) { TRUE && x } foo(c(a=FALSE)) # [1] FALSE # OK foo(c(a=TRUE)) # [1] TRUE # OK foo(c(a=FALSE)) # a # ???? # FALSE The 3rd call returned a result that it different from the 1st call! After

On 03/19/2016 01:22 AM, Michael Lawrence wrote: > > > On Sat, Mar 19, 2016 at 12:10 AM, Herv? Pag?s <hpages at fredhutch.org > <mailto:hpages at fredhutch.org>> wrote: > > On 03/18/2016 03:28 PM, Michael Lawrence wrote: > > > On Fri, Mar 18, 2016 at 2:53 PM, Herv? Pag?s > <hpages at fredhutch.org <mailto:hpages at

Hi, After I create a long list e.g. with x <- vector(mode="list", length=3e9) many bad things start to happen e.g. some things stop working with a spurious error message: gc() # Error in gc() : # long vectors not supported yet: /home/hpages/src/R-3.3.2/src/main/memory.c:1137 x_lens <- lengths(x) # Error in lengths(x) : # long vectors not supported yet: