similar to: Need car() and cdr() for '...'

Is there a means to split a vector into its individual elements without going the brute-force route for arguments to a predefined function call? offred.rgb <- c(1, 0, 0) * 0.60; ## Brute force style offred.col <- rgb(offred.rgb[1], offred.rgb[2], offred.rgb[3], names = "offred") ## Desired style

I want the equivalent of this 'C' declaration. enum StoplightColor { green = 3, yellow = 5, red = 7 }; This mostly works except the validity checking doesn't seem to occur automatically. What didn't I do to enable it? setClass("stoplightColor", representation(value = "integer"), prototype = integer(1))

On Sun, 11 Jul 2004, Gabor Grothendieck wrote: > search.path <- > function(fn, > paths = strsplit(Sys.getenv("PATH"), split = ";")[[1]], > fsep = "\\") { > for(d in paths) { > f <- file.path(d, fn, fsep = fsep) > if (file.exists(f)) > return(f) > } > return(NULL) > } >

I'm translating some Matlab code and need some help figuring out how to change this call into an S4 generic method. In matlab, there's a function called 'repmat' with three calling sequences (all I have to deal with anyway): 1) B = repmat(A, m, n) 2) B = repmat(A, [m n]) 3) B = repmat(A, n) In all cases, A is the fill value, m is number of rows, and n is number of

Anyone aware of tools available that can provide complexity metrics and/or code coverage analysis for R source? ---------------------------------------------------------- SIGSIG -- signature too long (core dumped)

R 2.1.0/src/include from 2005/04/18 download Naming inconsistent for guards as well but that's pedantic. Simple convention: file <foo.h> #ifndef R_FOO_H file <R_ext/bar.h> #ifndef R_EXT_BAR_H Missing guards: <IOStuff.h> <Internal.h> <Parse.h> <R_ext/GraphicsBase.h> <R_ext/GraphicsDevice.h> <R_ext/GraphicsEngine.h>

Had been looking into Luke Tierney's R_AllocatePtr() and was left with a question about exactly when does R reclaim heap memory. Implication of 'simpleref.nw' is that one can allocate C data on the R heap, and as long as pointer object is alive, the data and pointer will remain valid. But it calls allocString() which is implemented using R_alloc(). 'Writing R Extensions" says

Is there a canonical means to apply a function over multiple arrays simultaneously? For example, if I wanted to plot each line with a different color? Or is a for loop conversion my best option? x <- seq(0, 8, by = 2) y <- matrix(1:15, nrow = 5, byrow = TRUE) my.colors <- heat.colors(3) drawLines <- function(row) { lines(x, row) # want corresponding 'my.colors' here }

Hallo, does a package for Matlab exist in R? If yes, where can I find it and how can I install it under R? Thanks, Corinna

Hi, I'm trying to get C code working with R. This is my first time writing C on Windows and I'm making a mess of it. Help! I'm following the example in Roger Peng's "An Introduction to the .C interface to R". The C code is: #include <R.h> void hello(int *n){ int i; for(i=0; i < *n; i++) { Rprintf("Hello, world!\n"); } } I seem to be unable

I have some code where the primary dispatching is on other parameters so I'd like not to have to create a set of functions for "matrix" and another duplicate set for "array". But the class union technique isn't working as implemented below and I don't have my Green book with me. How do I fix my infinite recursion problem?

I recently encountered this and was wondering if someone could explain what happened. Basis of question involves what the difference between the calls makes as the end result is the same: > identical(matrix(1:8, nrow = 1), array(1:8, c(1, 8))) TRUE If I run the code below as shown, I get the following: > foo(1:8, 4) foo (vector, numeric) val = 4 foo (matrix, ANY) val = 500 foo

What a delicious example! (I'm taking the liberty of sharing it with r-devel, since it raises some good issues.) You have two questions, presumably: 1 - how could the order of the setMethod calls make a difference in the results? 2 - what's causing the infinite loop & how could it be avoided, reliably? Second question first. The danger sign is the "vector" method:

Is it possible for S4 to (continue) dispatch to a class created during dispatching? The code below doesn't work; is this not possible or have I ommitted something? Concept was to create a SEXP with R_AllocatePtr, give it a class attribute, and continue dispatch. Example code below omits multiple parameters that can be different types. Essentially, any parameter would be converted to an

Can someone explain what the problem is when I use the generating function? And how to get debug() to stop in the Superclass initialize method? ---- source ----- setClass("Superclass", representation(id = "character"), contains = "VIRTUAL") setMethod("initialize", signature(.Object = "Superclass"),

I'm attempting to reflect the information for use with corresponding fields in GUI (in a different package), to provide default values, argname as key for UI label lookups, etc. So I want something much more like the formals of the implementation: { "object", "method": c("median", "vs", "tukey"),

Interrogating some (of my own) code in another package. >norm.meth <- getMethod("normalize", "MatrixLike") >message("str(norm.meth)") >str(norm.meth) >message("show(norm.meth at .Data)") >show(norm.meth at .Data) Last show() displays this: function (object, ...) { .local <- function (object, method = c("median",

Late to the show on this release, unfortunately. One of our production packages no longer builds under R-2.15.0 with the following message. ** testing if installed package can be loaded Error: Function found when exporting methods from the namespace 'SuperCurve' which is not S4 generic: 'image' Possibly relevant clues follow: ## From R/AllGenerics.R if

I have trouble finding applicable examples of S4 methods. Could someone tell me the canonical method for a function that takes either one or two arguments corresponding to dimensions? So if vector output desired, only one argument 'n' would be provided. For matrix, two would be provided corresponding to 'm' and 'n' in that order. And therein lies the rub as I don't

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