similar to: combining generics/methods from multiple packages

I?m preparing a package (fastR) for submission to CRAN, but the vignette index keeps going AWOL, or at least R CMD check ?as-cran thinks so. I?ve tried several things and gave myself the weekend to think of other things, but I can?t figure it out. Perhaps someone on the list can lend a hand. Here?s one example situation, where I build the index.html file myself and put it in inst/doc/index.html

I see that the sigma() function has recently been introduced into R 3.3. The help for sigma() says: Extract the estimated standard deviation of the errors, the ?residual standard deviation? (misnomed also ?residual standard error?, e.g., in summary.lm()'s output, from a fitted model. Is there any reason not to fix the mis-naming of residual standard error now too? Both functions are in the

First a bit of background: After doing a search for a flexible polar plot function and coming up empty, I have begun writing one myself. Since I am new to writing mid-level graphics routines, this has required some learning about lattice, grid and related things. I am to the point where I have a workable proof of concept, but still need to make some improvements. My goal is to have

>>>>> Randall Pruim <rpruim at calvin.edu> >>>>> on Sun, 17 Apr 2016 13:54:28 +0000 writes: > I see that the sigma() function has recently been introduced into R 3.3. The help for sigma() says: > Extract the estimated standard deviation of the errors, the ?residual standard deviation? (misnomed also ?residual standard error?, e.g., in

One of the products of Project MOSAIC (funded by an NSF CCLI grant) has been the development of an R package with the goal of making it easier to use R, especially in teaching situations. We're not quite ready to declare that we've reached version 1.0, but version 0.4 does represent a fairly large step in that direction. You can find out more about the package on CRAN or by installing

One of the products of Project MOSAIC (funded by an NSF CCLI grant) has been the development of an R package with the goal of making it easier to use R, especially in teaching situations. We're not quite ready to declare that we've reached version 1.0, but version 0.4 does represent a fairly large step in that direction. You can find out more about the package on CRAN or by installing

In the examples below, the first loses the name attached by foo(), the second retains names attached by bar(). Is this an intentional difference? I?d prefer that the names be retained in both cases. foo <- function(x) { c(mean = base::mean(x)) } bar <- function(x) { c(mean = base::mean(x), sd = stats::sd(x))} aggregate(iris$Sepal.Length, by = list(iris$Species), FUN = foo) #>

On Fri, Mar 23, 2018 at 6:43 PM, Rui Barradas <ruipbarradas at sapo.pt> wrote: > Hello, > > Not exactly an answer but here it goes. > If you use the formula interface the names will be retained. Also if you pass named arguments: aggregate(iris["Sepal.Length"], by = iris["Species"], FUN = foo) # Species Sepal.Length # 1 setosa 5.006 # 2

Dear Hadley, There's been some mails from you lately about packages on R-devel. I would argue that the appropriate list for that is R-pkg-devel, as I've been told myself not too long ago. People might get confused and think this is about a change to R itself, which it obviously is not. Kind regards Joris On Thu, Aug 23, 2018 at 8:32 PM Hadley Wickham <h.wickham at gmail.com>

First, some general comments: This sounds like a useful package. I would guess it has very little impact on runtime efficiency except when attaching a new package; have you checked that? I am not so sure about your heuristics. Can they be disabled, so the user is always forced to make the choice? Even when a function is intended to adhere to the superset principle, they don't always

Hadley, Overall seems like a cool and potentially really idea. I do have some thoughts/feedback, which I've put in-line below On Thu, Aug 23, 2018 at 11:31 AM, Hadley Wickham <h.wickham at gmail.com> wrote: > > <snip> > > conflicted applies a few heuristics to minimise false positives (at the > cost of introducing a few false negatives). The overarching goal is

This issue ties loosely into other recent S4 topics on this board. The methods package defines a number of implicit generics for linear algebra related functions (rcond, norm, backsolve) that, when used, interfere with base package operations. Here is the cut-and-paste version of the code the illustrates the problem: # rcond x1 <- cbind(1, 1:10) rcond(x1) setGeneric("rcond")

If you have to load two packages which both export the same name in their namespaces, namespace does not help in resolving which synonymous function to use. Neither does it help to have a package instead of a script as long as you end up loading two namespaces with name conflicts. The order of importing namespaces can also be difficult to control, because you may end up loading a namespace already

I have some questions about S4 style methods and generics. First of all, is there any way of using default values for arguments in the generics/methods? My own experiments show that such arguments are always ignored. The green book seems to be silent on this matter. The second question is about using a non-trivial function body for generics. Page 351 of the green book gives an example of this

Dear list, It seems that S4 methods defined for an S3 'base' generic are not used in 'base' functions. This can be problematic when 'base' functions start with something like 'as.matrix'. ### START R code setClass("classA", contains = "matrix", representation(realData = "numeric")) setMethod("as.matrix",

Hi all, I?d love to get your feedback on the conflicted package, which provides an alternative strategy for resolving ambiugous function names (i.e. when multiple packages provide identically named functions). conflicted 0.1.0 is already on CRAN, but I?m currently preparing a revision (<https://github.com/r-lib/conflicted>), and looking for feedback. As you are no doubt aware, R?s default

I'm getting an R CMD check warning with a package (call it package A) that defines an S3 method but not the generic. The generic is defined in another package (package B). Package A imports the S3 generic from B. And there's one additional detail: the generic overrides a function in the stats package. I've created a minimal test package which reproduces the problem:

I have a series of question about methods and generics. The questions are interspersed in some text which explains what I want to do, how it works now and why I do not understand well why it works. Questions are written Q1 and so on up to Q9 and always start a new line. The concrete problem is this: it has become customary after a meta-analysis to quote various statistics to give a picture of the

Hi all, I've noticed a couple of small bugs/documentation errors related to S3 internal and group generics: * In ?S3groupGeneric, log2 and log10 are not listed as group generics, even though they are in the equivalent S4 groups, and are the source code for do_log1arg contains DispatchGroup("Math", ...) * As well as log2 and log10, tools:::.get_internal_S3_generics() fails to

You can get what you are asking for now in R 4.0.0 with globalCallingHandlers and using the packageConflictError object that is signaled. This should get you started: ``` options(conflicts.policy = "strict") packageConflictError handle_conflicts <- function(e) { cat(conditionMessage(e)) opt <- readline(prompt="1: mask.ok; 2: exclude. Choose: ") if (opt