similar to: simplify2array edge case

You?re right, it sure does. My suggestion causes it to fail when simplify = ?array? From: William Dunlap [mailto:wdunlap at tibco.com] Sent: Tuesday, March 13, 2018 12:11 PM To: Doran, Harold <HDoran at air.org> Cc: r-help at r-project.org Subject: Re: [R] Possible Improvement to sapply Wouldn't that change how simplify='array' is handled? > str(sapply(1:3,

Wouldn't that change how simplify='array' is handled? > str(sapply(1:3, function(x)diag(x,5,2), simplify="array")) int [1:5, 1:2, 1:3] 1 0 0 0 0 0 1 0 0 0 ... > str(sapply(1:3, function(x)diag(x,5,2), simplify=TRUE)) int [1:10, 1:3] 1 0 0 0 0 0 1 0 0 0 ... > str(sapply(1:3, function(x)diag(x,5,2), simplify=FALSE)) List of 3 $ : int [1:5, 1:2] 1 0 0 0 0 0 1 0 0

Jean-Claude: Well, here's my "explanation". Caveat emptor! Note that: "simplify2array() is the utility called from sapply() when simplify is not false" and > sapply(a, I, simplify = "array") [,1] [,2] [1,] list,2 list,2 [2,] list,2 list,2 So it seems that simplify2array() is not intended to operate in the way that you expected, i.e. that recursive

Reading the doc for ?simplify2array, I got the impression that with the 'higher = T' argument the function returns an array of dimension greater than 2 when it makes sense (the doc says "when appropriate", which is rather vague). I would expect a <- list( list(list(1, 2), list(3, 4)), list(list(5, 6), list(7, 8)) ) simplify2array(a, higher = T) to return the same

If x has an S3 class then sort.int(x) returns a value without an S3 class but which has the is.object flag set, which, I think, causes identical() give a false/misleading report: > x <- structure(1:3, class="unrecognizedClass") > y <- sort.int(x) > t <- 1:3 > identical(y, t) # expect TRUE [1] FALSE > identical(as.vector(y), as.vector(t)) # expect

Our firm would like to route support requests through a website instead of using email. However R will refuse to install a package if DESCRIPTION's Maintainer field does not have a valid email adress or the special value "ORPHANED". (The check is done with tools:::.valid_maintainer_field_regexp.) I imagine a typical Maintainer line for the package "foo" might be

I am curious if anyone knows of R code where the "{" function is redefined in a useful way. Or "(" for that matter. Thanks Mick

Thank you for the suggestion, Bill. The result is not quite what I would like. Here's sample code for you or anyone else who may be interested: Al1 = c('A','C','C','C') Al2 = c('G','G','G','T') Freq1 = c(0.0078,0.0567,0.9434,0.9908) MAF = c(0.0078,0.0567,0.0566,0.0092) m1 = data.frame(Al1=Al1,

(a) In R 2.12.2 rowsum can overflow if given an integer input: > rowsum(c(2e9L, 2e9L), c("a", "a")) [,1] a -294967296 > 2^32 + .Last.value [,1] a 4e+09 Should it be changed to coerce its x argument to numeric (double precision) so it always returns a numeric output? (b) When rowsum is given an x containing both NaN and NA it appears to use the last

Should there be a [[<-.factor() that either throws an error or acts like [<-.factor() to avoid making an illegal object of class factor? > z <- factor(c("Two","Two","Three"), levels=c("One","Two","Three")) > z [1] Two Two Three Levels: One Two Three > str(z) Factor w/ 3 levels

dir(all=TRUE) returns the file names "." and ".." while dir(recursive=TRUE, all=TRUE, include.dirs=TRUE) does not. I always filter out the "." and ".." entries and was wondering if anyone would mind if dir(all=TRUE) just omitted them? It might make recursive file operations like cleaning out a directory safer, as unlink(recursive=TRUE, dir(all=TRUE,

Quite possibly, and I?ll look into that. Aside from the work I was doing, however, I wonder if there is a way such that sapply could avoid the overhead of having to call the identical function to determine the conditional path. From: William Dunlap [mailto:wdunlap at tibco.com] Sent: Tuesday, March 13, 2018 12:14 PM To: Doran, Harold <HDoran at air.org> Cc: Martin Morgan <martin.morgan

With a pretty recent version of R 2.11.0 (devel,unstable, svn 50178) on Linux I could not install version 1.5-8 of zoo (the current on on CRAN): % R-devel CMD INSTALL -l Rlib3 zoo * installing *source* package 'zoo' ... ** R ** inst ** preparing package for lazy loading ** help *** installing help indices converting help for package 'zoo' finding

R version 2.10.0 Under development (unstable) (2009-09-08 r49628) Here are two somewhat related questions. First, when we attach a too short names vector to a vector the names vector is padded with NA's to the length of the main vector: E.g., > x<-1:3 > names(x)<-c("One","Two") > str(x) Named int [1:3] 1 2 3 - attr(*, "names")=

I was looking for all the glm-related 'family' functions in stats using the following predicate that returns TRUE for any function whose first argument is called "link". is.family <- function(object) is.function(object) && identical(names(as.list(object))[1], "link") It threw an error when applied to SSfol > is.family(SSfol) Error in

While working with sapply, the documentation states that the simplify argument will yield a vector, matrix etc "when possible". I was curious how the code actually defined "as possible" and see this within the function if (!identical(simplify, FALSE) && length(answer)) This seems superfluous to me, in particular this part: !identical(simplify, FALSE) The preceding

Is there an R-language interface to the R API C-language functions Rf_logspace_add() and Rf_logspace_sub()? I don't see one but I may not looking under the right name. Various packages have functions which do that same sort of thing (log(exp(x)+exp(y)) and log(exp(x)-exp(y)) without unnecessary floating point errors). They have names like matrixStats::logSumExp(lx, na.rm=FALSE, ...)

Should the F statistic be the same when using add1() on models created by lm and glm(family=gaussian)? They are in the single-degree-of-freedom case but not in the multiple-degree-of-freedom case. MASS:addterm shows the same discrepancy. It looks like the deviance (==residual sum of squares) gets divided by the number of degrees of freedom for the term twice in add1.glm. Using anova() on the

With today's R 2.10.0(devel) I get: > anyDuplicated(c(1,NA,3,NA,5), incomp=NA) # expect 0 Warning: stack imbalance in 'anyDuplicated', 20 then 21 Warning: stack imbalance in '.Internal', 19 then 20 Warning: stack imbalance in '{', 17 then 18 [1] 0 > anyDuplicated(c(1,NA,3,NA,3), incomp=NA) # expect 5 Warning: stack imbalance in 'anyDuplicated', 20 then 21

On Linux when I compile R 2.10.0(devel) (src/main/arithmetic.c in particular) with gcc 3.4.5 using the flags -g -O2 I get noncommutative behavior when adding NA and NaN: > NA_real_ + NaN [1] NaN > NaN + NA_real_ [1] NA If I compile src/main/arithmetic.c without optimization (just -g) then both of those return NA. On Windows, using a precompiled R 2.8.1 from CRAN I get NA for