similar to: often unnecessary duplicate in sapply / as.vector

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".

Dario, What version of R are you using. In my mildly old 3.4.0 installation and in the version of Revel I have lying around (also mildly old...) I don't see the behavior I think you are describing > b = by(1:2, 1:2, identity) > class(as.list(b)) [1] "list" > sessionInfo() R Under development (unstable) (2017-12-19 r73926) Platform: x86_64-apple-darwin15.6.0 (64-bit)

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. Michael On Tue, Jan 30, 2018 at 2:41 PM, Herv? Pag?s <hpages at fredhutch.org> wrote: > Hi Gabe, > > Interestingly the behavior of as.list() on by objects seem to

Hello everyone, I am reading a HTML table from a website with readHTMLTable() from the XML package: > library(XML) > moose = readHTMLTable("http://www.decisionmoose.com/Moosistory.html", header=FALSE, skip.rows=c(1,2), trim=TRUE)[[1]] > moose V1 V2 V3 1 07.02.2010 SWITCH to Long Bonds\n (BTTRX)

>>>>> 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

Using: untrace(methods::conformMethod) at <- c(12,4,3,2) str(body(methods::conformMethod)[[at]]) ## language omittedSig <- omittedSig && (signature[omittedSig] != "missing") cc <- 0L trace(methods::conformMethod, tracer = quote({ cc <<- cc + 1L print(cc) if (cc == 31) { ## manually identified untrace(methods::conformMethod)

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

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

The following code results in a seg fault. > sessionInfo() R version 2.6.0 Under development (unstable) (2007-06-21 r42013) x86_64-unknown-linux-gnu locale: LC_CTYPE=en_US;LC_NUMERIC=C;LC_TIME=en_US;LC_COLLATE=en_US;LC_MONETARY=en_US;LC_MESSAGES=en_US;LC_PAPER=en_US;LC_NAME=C;LC_ADDRESS=C;LC_TELEPHONE=C;LC_MEASUREMENT=en_US;LC_IDENTIFICATION=C attached base packages: [1] stats graphics

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,

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

all/any coerce their arguments to logical (if possible). I've added a warning in R-devel if coercion is from something other than integer. This arose because it is easy to make a slip and write all(X) > 0 rather than all(X > 0): thanks to Bill Dunlap for bringing that to my attention. However, it has been useful in detecting quite a few other things: - indices which had been made

>>>>> Martin Maechler <maechler at lynne.stat.math.ethz.ch> >>>>> on Fri, 17 Apr 2015 15:49:35 +0200 writes: >>>>> Herv? Pag?s <hpages at fredhutch.org> >>>>> on Mon, 13 Apr 2015 23:36:14 -0700 writes: >> On 04/13/2015 11:32 PM, Martin Maechler wrote: >>> >>>> Hi,

Hey guys, I noticed something curious in the lapply call. I'll copy+paste the function call here because it's short enough: lapply <- function (X, FUN, ...) { FUN <- match.fun(FUN) if (!is.vector(X) || is.object(X)) X <- as.list(X) .Internal(lapply(X, FUN)) } Notice that lapply coerces X to a list if the !is.vector || is.object(X) check passes. Curiously,

On 04/13/2015 11:32 PM, Martin Maechler wrote: > >> Hi, >> > as.integer("5000000000") >> [1] 2147483647 >> Warning message: >> inaccurate integer conversion in coercion > >> > as.integer("-5000000000") >> [1] NA >> Warning message: >> inaccurate integer conversion in coercion >

I just got the same error message with > sessionInfo() R version 3.4.0 (2017-04-21) Platform: x86_64-apple-darwin15.6.0 (64-bit) Running under: macOS Sierra 10.12.4 Matrix products: default BLAS: /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libBLAS.dylib LAPACK: /Library/Frameworks/R.framework/Versions/3.4/Resources/lib/libRlapack.dylib

Hi, > as.integer("5000000000") [1] 2147483647 Warning message: inaccurate integer conversion in coercion > as.integer("-5000000000") [1] NA Warning message: inaccurate integer conversion in coercion Is this a bug or a feature? The man page suggests it's the latter: ?as.integer? attempts to coerce its argument to be of integer type.

Hi All, I am attempting to work with some data from loggers. I have read in a .csv exported from MS Access that already has my dates and times (in 24 clock format), (with StringsAsFactors=FALSE). > head(tdata) LogData date time 1 77.16 2008/04/24 02:00 2 61.78 2008/04/24 04:00 3 75.44 2008/04/24 06:00 4 89.43 2008/04/24

Is the following behaviour of tapply not disappointing? Problem with tapply occurs when dealing with na.rm when an argument additional to na.rm is sent to the applied function (here quantile). Any comment? Thank you, Philippe Lambert > x <- c(12,10,12,2,4,11,3,7,2,1,18,7,NA,NA,7,5) > fac <- gl(4,4,16) > # Works fine > tapply(x,fac,quantile,na.rm=T) $"1" 0% 25%

Hello everybody, This is a bug involving functions in core R package: graphics::hist.default, grDevices::nclass.FD, and base::pretty.default. It is not yet on Bugzilla. I cannot submit it myself, as I do not have an account. Could somebody else add it for me, perhaps? That would be much appreciated. Kind regards, Sietse Sietse Brouwer Summary ------- Floating point errors can cause a data