search for: phaverti

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

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",

How about unique them both and compare the lengths? It's less work, especially allocation. Pete ____________________ Peter M. Haverty, Ph.D. Genentech, Inc. phaverty at gene.com On Thu, Jan 8, 2015 at 1:30 PM, peter dalgaard <pdalgd at gmail.com> wrote: > If you look at the definition of %in%, you'll find that it is implemented > using match, so if we did as you suggest,

Hi all, Profiling turned up a bit of a speedbump in the library function. I submitted a patch to the R bug tracker as bug 16168 and I've also included it below. The alternate code is simpler and easier to read/maintain, I believe. Any thoughts on other ways to write this? Index: src/library/base/R/library.R =================================================================== ---

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

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

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

Hi all, The function call series genericForPrimitive -> .findBasicFuns -> .findAll happens 4400 times while the GenomicRanges package is loading. Each time .findAll follows a chain of environments to determine that the methods namespace is the only one that holds a variable called .BasicFunsList. This accounts for ~10% of package loading time. I'm sure there is some history to that

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

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: > > 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

Hi All, I've been looking into speeding up the loading of packages that use a lot of S4. After profiling I noticed the "exists" function accounts for a surprising fraction of the time. I have some thoughts about speeding up exists (below). More to the point of this post, Martin M?chler noted that 'exists' and 'get' are often used in conjunction. Both functions are

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

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) {

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

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

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

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

>>>>> Martin Maechler <maechler at stat.math.ethz.ch> >>>>> on Fri, 9 Jan 2015 14:00:38 +0100 writes: >>>>> Michael Lawrence <lawrence.michael at gene.com> >>>>> on Thu, 8 Jan 2015 14:02:26 -0800 writes: >> On Thu, Jan 8, 2015 at 11:57 AM, <luke-tierney at uiowa.edu> wrote: >>> On Thu, 8