I'd like to transfer gCrisprTools to Russ Bainer (russ.bai...@gmail.com,
rbai...@mazetx.com). How do I do that?
[[alternative HTML version deleted]]
___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel
Dear Lori Shephard,
Yesterday it came to my attention that gCrisprTools is slated for
deprecation. Apparently, I've missed some related emails. Sorry about that.
I'm not sure why I didn't get them. I have pushed a fix for the bug to
master. Would it be possible to remove gCrisprTools from the depr
I'm working on using the new git setup. I've provided my GitHub user name
to BioC's form, so that my public key can be used with BioC's git. I
believe I was supposed to receive an email after that was set up, but I
have not. Is there something else I need to do?
Regards,
Pete
genoset has an is.unsorted for GenomicRanges. I profiled a bit and found a
pretty quick way to do it. My version ignores strand, so it is only proper
in some cases. But, maybe it's a head start on a fully general function.
Pete
Peter M. Haverty, Ph.D.
Genentech, Inc.
phave.
g has ranges.
>>
>> Vince: I am not claiming that it is easy to work with; we have pains as
>> well. But am I missing something or is the assay matrix only 2.3Gb?
>>
>> Best,
>> Kasper
>>
>> On Fri, Sep 18, 2015 at 6:28 PM, Peter Haverty
>> w
Yes, bigmemoryExtras::BigMatrix and genoset::RleDataFrame() are good tricks
for reducing the size of your eSets and SummarizedExperiments. Both object
types can go into assayData or assays. In fact, that's what they were
designed for.
At Genentech, we use these for our 2.5e6 x 1e3 rectangular dat
Those are all good reasons for keeping the strand by default. I'm on board.
Pete
Peter M. Haverty, Ph.D.
Genentech, Inc.
phave...@gene.com
On Fri, Apr 24, 2015 at 11:26 AM, Herv� Pag�s wrote:
> On 04/24/2015 11:08 AM, Peter Haverty wrote:
>
>> Good catc
ot;, which we
might want to support. The pmin/pmax stuff handles cases where the negative
strand is expressed by flipping start and stop. We might not need that.
Pete
Peter M. Haverty, Ph.D.
Genentech, Inc.
phave...@gene.com
On Fri, Apr 24, 2015 at 11:08 AM, Peter Haverty w
t;> It is a great idea, but I'm not sure I would use it to implement
>> table(). Allocating those strings will be costly. Don't we already
>> have the 4-way int hash? Of course, my intuition might be completely
>> off here.
&g
Would people be interested in having this:
setMethod("as.character", "GenomicRanges",
function(x) {
paste0(seqnames(x), ":", start(x), "-", end(x))
})
?
I find myself doing that a lot to make unique names or for output that
goes to collaborators. I suppose we m
Somewhere in GO.db a direct call to the ls .Internal is being made
(probably a speed hack) apparently. The API for .Internal(ls()) has
changed in R 3.2.0. This call should be replaced with "names", which now
works on environments in R 3.2.0, and is way faster than the direct call to
.Internal(ls()
management for
> expression arrays was hard, too. If I'm not mistaken, there were benefits
> to solving that data management problem, too. Some sort of a software
> project. I think it was called "MADMAN". I'll have to go look. ;-)
>
>
>
> Statistics
>> easily assert such contracts. For example, one could define an interface
>>> with a set of generics (and optionally the relevant position in the
>>> generic
>>> signature). Then, once all of the methods have been assigned for a
>>> particular class, it
iate-wise "holes" that
> could nonetheless be usefully imputed across assays.
>
>
> Statistics is the grammar of science.
> Karl Pearson <http://en.wikipedia.org/wiki/The_Grammar_of_Science>
>
> On Tue, Mar 3, 2015 at 3:25 PM, Peter Haverty
> wrote:
>
> > &g
>
>
>
> I still think GRanges should be a subclass of DataFrame,
>> which would make this easy, but I don't seem to be winning that argument.
>>
>
> Just impossible. As Michael mentioned back in November, they have
> conflicting APIs.
Maybe a new "GRangesFrame" that is a DataFrame and holds a GR
I'd like to see a basic class that takes a DataFrame and a sub-class that
takes a GRanges. I still think GRanges should be a subclass of DataFrame,
which would make this easy, but I don't seem to be winning that argument.
While the hood is up, can we try some different names?
SummarizedExperiment
My favorite solution to this would be to use Rcpp attributes to add R-level
functions for each C function. You can use these just for testing and skip the
exporting and manual pages. That's not quite what you asked for but it would
work.
BTW transcription factors are my thing so I'm eager to tr
There are few other changes in there too, but profiling did identify low
hanging fruit like the sapplys. From there I have found a long list of
refactoring opportunities that offer ~2% improvements. These may not be
worth the risk of reversions, however. I'll be putting together a patch
proposal wi
at 9:33 AM, Michael Lawrence wrote:
>
>
> On Wed, Nov 26, 2014 at 9:07 AM, Peter Haverty
> wrote:
>
>> Hi all,
>>
>> I believe there is a strong need for an object that organizes a collection
>> of rectangular data (matrices, etc.) with metadata on the rows
Hi all,
I believe there is a strong need for an object that organizes a collection
of rectangular data (matrices, etc.) with metadata on the rows and
columns. Can SummarizedExperiment inherit from something simpler that has
a DataFrame as rowData? (I believe GenomicRanges should inherit from
Dat
n, see here:
> http://git-scm.com/book/en/Git-and-Other-Systems-Git-and-Subversion
>
> Note that I don't personally have any experience with svn or with git-svn,
> but this seems like exactly the use case for it.
>
> -Ryan
>
>> On Fri 05 Sep 2014 04:50:49 PM PDT, Pet
Hi all,
I respectfully disagree. One should certainly check in each discrete unit
of work. These will often not result in something that is ready to be used
by someone else. Bumping the version number constitutes a new release and
carries the implicit promise that the package works again. This
; row/colMeans. Don't see a good reason to prefer columns over rows.
>
>
> On Mon, Jun 2, 2014 at 5:34 PM, Peter Haverty
> wrote:
>
>> I have have rangeColMeans which is essentially rangeMeans for
>> vector/matrix. I renamed this to make it a method on rangeMeans. I thin
ut first I want to move Rle's to the S4Vectors
>> package.
>>
>> Cheers,
>> H.
>>
>>
>>
>> On 06/01/2014 07:58 PM, Peter Haverty wrote:
>>
>>> I think viewMedians would be great. While you have the hood up, there
>>> are
&g
I think viewMedians would be great. While you have the hood up, there are
some opportunities for some speedups and code simplification, I believe.
I did some experimentation with view* in the genoset package. I made an
alternate version of the C for viewMeans and found about a 10X speedup. I
hoi
all for the change and
> its permanence
>
> --t
>
> > On Mar 25, 2014, at 9:31 AM, Peter Haverty
> wrote:
> >
> > One benefit of having dimnames on assays would be that one could use
> > DataFrames as assays, like in eSet. My genoset class is becoming mor
One benefit of having dimnames on assays would be that one could use
DataFrames as assays, like in eSet. My genoset class is becoming more and
more like SummarizedExperiment. The dimname issues prevent me from
switching entirely from eSet to SummarizedExperiment.
I think that keeping only one cop
27 matches
Mail list logo
