similar to: Aliasing a function

Has anyone developed a version of do.call that is safe in the sense that it silently drops parameters that do not appear in the formals of the called function? This is useful when ... ends up being used in multiple further functions. e.g. f <- function(a, b) {a + b} do.call(f, list(a=1, b=2, c=3)) # Errors safe.call(f, list(a=1, b=2, c=3)) # Returns 3 If have quickly thrown together the

That's very nice, Hadley. Simple and clean. Never would have thought of it myself. As usual, however, in the course of my churnings, I have a further complication to add. But first ... **TO ALL**: Feel free to ignore the following, as I'm just fooling around here and don't want to waste your time with my stupid stuff. Anyway, the complication is motivated by the use of formals() or

Hi all, I think there's a small buglet in quote: str(quote()) # Error in quote() : 0 arguments passed to 'quote' which requires 1 str(quote(expr = )) # symbol I bring this up because this seems like the most natural way of capturing the "missing" symbol with pure R code, compared to substitute() or bquote() or formals(plot)$x Hadley -- Chief Scientist, RStudio

I might add that there seems to be a subtle difference between using `...elt()` and `match.call()`, which is that the former causes `a` itself to be evaluated while the latter doesn't: ``` # Some approaches that have been suggested: # 1. Using `list()` (Bert Gunter) f1 <- function(...) list(...)[["a"]] # 2. Using `...elt()` (Bert Gunter) f2 <- function(...)

Hi all, What's the official name for the value that represents a missing argument? e.g. formals(plot)$x str(formals(plot)$x) deparse(formals(plot)$x) is.symbol(formals(plot)$x) What's the correct way to create an object like this? (for example if you are manipulating the formals of a function to add an argument with no default value, as in http://stackoverflow.com/questions/3892580/).

Hello R useRs, I have a function which returns a list of functions : freq1 <- function(x) { lev <- unique(x[!is.na(x)]) nlev <- length(lev) args <- alist(x=) if (nlev == 1) { body <- c("{", "sum(!is.na(x))", "}") f <- function() {} formals(f) <- as.pairlist(args) body(f) <- parse(text = body) namef <-

I'd propose an alternative that I think is superior: rely on the semantics of ... to do the work for you: f1 <- function(...){ one <- list(...)[['a']] two <- ...elt(match('a', ...names())) c(one, two, three(...)) } three <- function(a, ...) { a } f1(a = 1, b = 2, c = 3) #> [1] 1 1 1 On Sun, Jan 5, 2025 at 12:00?PM Bert Gunter <bgunter.4567 at

I wish it didn't have to depend on the name '.local'. Back when I wrote a lot of S4 methods I avoided the auto-generated .local and named the local function something that made sense so that is was easier for a user to track down the source of an error. E.g., define the generic QQQ with numeric and integer methods: setGeneric("QQQ", function(x, ...)NULL)

Michael Lawrence (as last in long series of posters)... > Yes, it would bind the language object to the environment, like an > R-level promise (but "promise" of course refers specifically to just > _lazy_ evaluation). > > For the uqs() thing, expanding calls like that is somewhat orthogonal > to NSE. It would be nice in general to be able to write something like >

Is this the appropriate place for GSoC conversations? If I understand the proposal correctly, there should be a lexer (written in R) that exposes an API; that API would be used by segregated mini-parsers (Roclets) which do the dirty work of Roxygen -> {html, LaTeX, DocBook, ...} translation. The lexer should ship with a proof-of-concept Roclet. Have I missed anything?

Would we really need the special class or would simply checking the formals of the method against those of the generic be simple and fast enough? On Thu, Jan 29, 2015 at 9:41 AM, John Chambers <jmc at r-project.org> wrote: > I wouldn't want to add more to the current approach; if someone would like > to devote some time, the much preferable idea IMO would be to replace the >

Hi, Is there such a thing? If no: is it easily simulated? thanks, Joh

Dear all, I'm struggling with weighted least squares, where something that I had assumed to be true appears not to be the case. Take the following data set as an example: df <- data.frame(x = runif(100, 0, 100)) df$y <- df$x + 1 + rnorm(100, sd=15) I had expected that: summary(lm(y ~ x, data=df, weights=rep(2, 100))) summary(lm(y ~ x, data=rbind(df,df))) would be equivalent, but

(Under 2.2.0, Mac) I have been unable to reduce this to a simple case, so I'll include my full code, and my intentions. The problem I'm trying to solve is that while many defaults (eg. na.rm=F, drop=T) make sense for interactive programming, they tend to be a bit of a pain when developing a package. For example, I often forget to use drop=FALSE, only test with multiple columns and then

Hello all, I'm now using image() to show image data (in my case dumps of SOM weights) but would like to show RGB colour data, not just single "z" colour values. I've currently been using seq() to skip 4 values, so I can show the R, G or B channels separately as "z". But is there a way I can show all three channels simultaneously as a proper colour image? Thanks, B.

One of the recurring themes in the recent UserR conference was that many people find it difficult to find the functions they need for a particular task. Sandy Weisberg suggested a small idea he would like to see: a hints function that given an object, lists likely operations. I've done my best to implement this function using the tools currently available in R, and my code is included at the

One of the recurring themes in the recent UserR conference was that many people find it difficult to find the functions they need for a particular task. Sandy Weisberg suggested a small idea he would like to see: a hints function that given an object, lists likely operations. I've done my best to implement this function using the tools currently available in R, and my code is included at the

On Jan 28, 2015, at 6:37 PM, Michael Lawrence <lawrence.michael at gene.com> wrote: > At this point I would just due: > > formals(body(method)[[2L]]) > > At some point we need to figure out what to do with this .local() confusion. Agreed, definitely. The current hack is to avoid re-matching arguments on method dispatch, so a fix would need to be fairly deep in the

Just stating, in 'ifelse', 'test' is not recycled. As I said in "R-intro: length of 'ifelse' result" (https://stat.ethz.ch/pipermail/r-devel/2016-September/073136.html), ifelse(condition, a, b) returns a vector of the length of 'condition', even if 'a' or 'b' is longer. On current 'ifelse' code in R: * The part ans[nas] <- NA

Hi all, Very surprising (to me!) and mystifying result from predict.glm(): the predictions vary depending on whether or not I use ns() or splines::ns(). Reprex follows: library(splines) set.seed(12345) dat <- data.frame(claim = rbinom(1000, 1, 0.5)) mns <- c(3.4, 3.6) sds <- c(0.24, 0.35) dat$wind <- exp(rnorm(nrow(dat), mean = mns[dat$claim + 1], sd = sds[dat$claim + 1])) dat <-