similar to: RFC: deprecating some complexity in key methods package functions

I think that the "sorted" and "all.names" arguments are really only appropriate for pretty printing to the screen. I think it is a bit unfortunate that environments have a names accessor that is 60X slower than all the other types. This is likely due to the history of environments, which were originally just for behind-the-scenes tasks. Now that users can use environments as

>>>>> Michael Lawrence <lawrence.michael at gene.com> >>>>> on Tue, 27 Jan 2015 07:59:59 -0800 writes: > Since the contract of ls() is to sort, there is nothing wrong with > programmers depending on it. And there are many functions that could be > made 60X faster, but is it worth it? But I did notice that > as.list.environment

Hi all, I use Luke's "::" hoisting trick often. I think it would be fantastic if the JIT just did that for you. The main trouble, for me, is in code I don't own. When common Bioconductor packages are loaded many, many base functions are saddled with this substantial dispatch and "::" overhead. While we have the hood up, the parser could help out a bit here too. It

On Thu, Jan 29, 2015 at 5:51 AM, Martin Maechler < maechler at lynne.stat.math.ethz.ch> wrote: > >>>>> Michael Lawrence <lawrence.michael at gene.com> > >>>>> on Tue, 27 Jan 2015 07:59:59 -0800 writes: > > > Since the contract of ls() is to sort, there is nothing wrong with > > programmers depending on it. And there are

>>>>> Peter Haverty <haverty.peter at gene.com> >>>>> on Sun, 25 Jan 2015 12:21:04 -0800 writes: > Hi all, > The "ls" function wears two hats. It allows users to inspect an > environment interactively and also serves deeper in code as the > accessor for an environment's names/keys. I propose that we separate

Since the contract of ls() is to sort, there is nothing wrong with programmers depending on it. And there are many functions that could be made 60X faster, but is it worth it? But I did notice that as.list.environment has a sorted=FALSE argument already, so I guess identical(names(x), names(as.list(x))) could be made to be TRUE, assuming the order is at least persistent, if undefined, so that is a

I'm not convinced that how to make :: faster is the right question. If you are finding foo::bar being called often enough to matter to your overall performance then to me the question is: why are you calling foo::bar more than once? Making :: a bit faster by making it a primitive will remove some overhead, but your are still left with a lot of work that shouldn't need to happen more than

Hi all, The "ls" function wears two hats. It allows users to inspect an environment interactively and also serves deeper in code as the accessor for an environment's names/keys. I propose that we separate these two conflicting goals, keeping ls for interactive use and adding names for a quick listing of the hash keys. This involves adding two lines to do_names in attrib.c. The

On Thu, Jan 22, 2015 at 11:44 AM, <luke-tierney at uiowa.edu> wrote: > I'm not convinced that how to make :: faster is the right question. If > you are finding foo::bar being called often enough to matter to your > overall performance then to me the question is: why are you calling > foo::bar more than once? Making :: a bit faster by making it a > primitive will remove

I think ls(, sort=FALSE) would be more explicit and thus clearer. There is much precedent for having arguments that request less work to be done e.g. unlist(use.names=FALSE). Yes, the extra typing is a bit painful, but there is no intuitive reason why names() would be unsorted, while ls() would be sorted. While it is tempting to use an existing function for this, the word "names" is

On Thu, 22 Jan 2015, Michael Lawrence wrote: > On Thu, Jan 22, 2015 at 11:44 AM, <luke-tierney at uiowa.edu> wrote: >> >> For default methods there ought to be a way to create those so the >> default method is computed at creation or load time and stored in an >> environment. > > We had considered that, but we thought the definition of the function >

Hi, On 01/23/2015 07:01 AM, luke-tierney at uiowa.edu wrote: > On Thu, 22 Jan 2015, Michael Lawrence wrote: > >> On Thu, Jan 22, 2015 at 11:44 AM, <luke-tierney at uiowa.edu> wrote: >>> >>> For default methods there ought to be a way to create those so the >>> default method is computed at creation or load time and stored in an >>>

All, So that suggests that .GlobalEnv[["X"]] is more efficient than get("X", pos=1L). What about .GlobalEnv[["X"]] <- value, compared to assign("X", value)? Dave On Wed, Dec 3, 2014 at 3:30 PM, Peter Haverty <haverty.peter at gene.com> wrote: > Thanks Winston! I'm amazed that "[[" beats calling the .Internal > directly. I

I was thinking something like: setequal <- function(x,y) { xu = unique(x) yu = unique(y) if (length(xu) != length(yu)) { return FALSE; } return (all( match( xu, yu, 0L ) > 0L ) ) } This lets you fail early for cheap (skipping the allocation from the ">0L"s). Whether or not this goes fast depends a lot on the uniqueness of x and y and whether or not you want to optimize for

I also just noticed that there is a bug: identical(ans, FALSE) should be is.null(ans). So no error is thrown: > methods:::genericForPrimitive("foo") NULL Will fix. On Wed, Jan 21, 2015 at 3:13 PM, Peter Haverty <haverty.peter at gene.com> wrote: > Doing it like this: > > genericForPrimitive <- function(f, where = topenv(parent.frame()), mustFind > = TRUE) {

Hi all, When S4 methods are defined on base function (say, "match"), the function becomes a method with the body "base::match(x,y)". A call to such a function often spends more time doing "::" than in the function itself. I always assumed that "::" was a very low-level thing, but it turns out to be a plain old function defined in base/R/namespace.R. What

Doing it like this: genericForPrimitive <- function(f, where = topenv(parent.frame()), mustFind = TRUE) { ans = .BasicFunsList[[f]] ## this element may not exist (yet, during loading), dom't test null if(mustFind && identical(ans, FALSE)) stop(gettextf("methods may not be defined for primitive function %s in this version of R",

On Thu, Jan 22, 2015 at 11:44 AM, <luke-tierney at uiowa.edu> wrote: > > For default methods there ought to be a way to create those so the > default method is computed at creation or load time and stored in an > environment. We had considered that, but we thought the definition of the function would be easier to interpret if it explicitly specified the namespace, instead of

Thanks Winston! I'm amazed that "[[" beats calling the .Internal directly. I guess the difference between .Primitive vs. .Internal is pretty significant for things on this time scale. NULL meaning NULL and NULL meaning undefined would lead to the same path for much of my code. I'll be swapping out many exists and get calls later today. Thanks! I do still think it would be

I think you can simplify a little by replacing this: pkg %in% loadedNamespaces() with this: .getNamespace(pkg) Whereas getNamespace(pkg) will load the package if it's not already loaded, calling .getNamespace(pkg) (note the leading dot) won't load the package. I can't speak to whether there are any pitfalls in changing the library path searching, though. -Winston On Thu, Jan