similar to: iterated lapply

Would introducing the new frame, with the call to local(), cause problems when you use frame counting instead of <<- to modify variables outside the scope of lapply's FUN, I think the frame counts may have to change. E.g., here is code from actuar::simul() that might be affected: x <- unlist(lapply(nodes[[i]], seq)) lapply(nodes[(i + 1):(nlevels - 1)],

Hi everybody, with the following code I generate a list of functions. Each function reflects a "condition". When I evaluate this list of functions by another lapply/sapply, I get an unexpected result: all values coincide. However, when I uncomment the print(), it works as expected. Is this a bug or a feature? conditions <- 1:4 test <- lapply(conditions, function(mycondition){

The documentation is not specific enough on the indented semantics in this situation to consider this a bug. The original R-level implementation of lapply was lapply <- function(X, FUN, ...) { FUN <- match.fun(FUN) if (!is.list(X)) X <- as.list(X) rval <- vector("list", length(X)) for(i in seq(along = X)) rval[i]

On 23/02/2015 3:57 PM, Daniel Kaschek wrote: > Hi everybody, > > with the following code I generate a list of functions. Each function > reflects a "condition". When I evaluate this list of functions by > another lapply/sapply, I get an unexpected result: all values coincide. > However, when I uncomment the print(), it works as expected. Is this a > bug or a

> On Feb 24, 2015, at 10:50 AM, <luke-tierney at uiowa.edu> wrote: > > The documentation is not specific enough on the indented semantics in > this situation to consider this a bug. The original R-level > implementation of lapply was > > lapply <- function(X, FUN, ...) { > FUN <- match.fun(FUN) > if (!is.list(X)) > X <-

> On Feb 25, 2015, at 5:35 PM, Benjamin Tyner <btyner at gmail.com> wrote: > > Actually, it depends on the number of cores: Under current semantics, yes. Each 'stream' of function calls is lazily capturing the last value of `i` on that core. Under Luke's proposed semantics (IIUC), the result would be the same (2,4,6,8) for both parallel and serial execution. This is

Actually, it depends on the number of cores: > fun1 <- function(c){function(i){c*i}} > fun2 <- function(f) f(2) > sapply(mclapply(1:4, fun1, mc.cores=1L), fun2) [1] 8 8 8 8 > sapply(mclapply(1:4, fun1, mc.cores=2L), fun2) [1] 6 8 6 8 > sapply(mclapply(1:4, fun1, mc.cores=4L), fun2) [1] 2 4 6 8 > >/ On Feb 24, 2015, at 10:50 AM,

> There are other instances, such as Reduce where there is a bug > report pending that amounts to the same issue. Performing surgery on > expressions and calling eval is not good practice at the R level and > probably not a good idea at the C level either. It is worth thinking > this through carefully before a adopting a solution, which is what we > will be doing. Surgery on

I think the discussion of this issue has gotten more complicated than necessary. First, there really is a bug. You can see this also by the fact that delayed warning messages are wrong. For instance, in R-3.1.2: > lapply(c(-1,2,-1),sqrt) [[1]] [1] NaN [[2]] [1] 1.414214 [[3]] [1] NaN Warning messages: 1: In FUN(c(-1, 2, -1)[[3L]], ...) : NaNs produced 2: In

Below is an example of a problem I encounter repeatedly when I write functions. A call works at the command line, but it does not work inside a function, even when I have made sure that all required variables are available within the function. The only way I know to solve it is to make the required variable global, which of course is dangerous. What is the elegant or appropriate way to solve

Hi Óscar, Thank you for your prompt reply. Unfortunately, I still need more guidance as using the Demo page to generate C++ code didn't result in a global variable being used. Basically, I'm following your advice to use a LoadInst: Value *v = new LoadInst(result, "", theBasicBlock); Function *myfn = cast<Function>(v); I was not sure how I could get a BasicBlock for the

Hi, I have the following hypothetical optimization problem: -det(t(x-A%*%x1)%*%(x-A%*%x1)) where A,x,x1 are matrices. A coefficients and x and x1 are variable matrices or vectors. I tried to apply optim and nlm functions but I kept receive the following massage: Error in A%*%x1 : non-conformable arguments. The massage appears even the -det() can be calculated and the dimensions are checked. here

I am trying to build a C language DLL and it works well with i386 but when I compile with it substituted by x64, like the FAQ page says, the result is an error message: C:/PROGRA~1/R/R-214~1.0/bin/x64/R.ddl: file not recognized : File format not recognized collect2: ld returned 1 exit status How can I solve this? The problem is with R 2-14.0 and 2-13.0 The complete source code is /* * myfun.c

I tried to use lsode with precompiled C code instead of an R function defining the derivatives. No problem so far. However, now I need to implement an ODE that contains spline functions, i.e. the derivatives at given time points depend on the value of a spline function at this time point. What is an efficient way to implement this in precompiled C code? -- Daniel Kaschek <daniel.kaschek at

Hi, I would like to write a function which has the following syntax: myfn <- function(formula, ftime, fstatus, data) { # step 1: obtain terms in `formula' from dataframe `data' # step 2: obtain ftime from `data' # step 3: obtain fstatus from `data' # step 4: do model estimation # step 5: return results } The user would call this function as: myfn(formula=myform,

Hi All, I have a formula which has a factor with NAs in it. I wish to keep these in the model matrix, but the NA information is currently lost (the rows are kept but the NA gets converted to 0). Any ideas as to how I can keep NAs in? e.g. junk <-

I have an application where I need to preserve object attributes across calls to 'lapply'. The current definition is: lapply <- function (X, FUN, ...) { FUN <- match.fun(FUN) if (!is.list(X)) X <- as.list(X) rval <- .Internal(lapply(X, FUN)) names(rval) <- names(X) return(rval) } Would it make sense to replace names(rval) <- names(X)

On 9/13/2013 6:06 PM, Nick Kledzik wrote: > On Sep 13, 2013, at 3:35 PM, Shankar Easwaran <shankare at codeaurora.org> wrote: >> This would work only if an alias is another name for the same symbol(weak symbols). > I don’t know what that means. Can you clarify? Doesnt this imply that the alias atom is a zero sized atom ? >> If what is being aliased is another function

On Sun, 1 Mar 2015, Radford Neal wrote: > I think the discussion of this issue has gotten more complicated than > necessary. The discussion has gotten no more complicated than it needs to be. There are other instances, such as Reduce where there is a bug report pending that amounts to the same issue. Performing surgery on expressions and calling eval is not good practice at the R level

Sometimes one might like to obtain pointwise bootstrap bias-corrected, accelerated (BCA) confidence intervals for a large number of statistics computed from a single dataset. For instance, one might like to get (so as to plot graphically) bootstrap confidence bands for the fitted values in a regression model. (Example: Chiu S et al., Early Acceleration of Head Circumference in Children with