[Bioc-devel] [BioC] granges() method for GenomicRanges objects akin to ranges()...
Hi,
On 05/13/2014 01:15 AM, Julian Gehring wrote:
Hi, In summary, would it be feasible to add to 'GenomicRanges'? 1) A 'granges(x, use.mcols=FALSE, ...)' method with signature 'GRanges' that converts to a 'GRanges' object and optionally drops the mcols (if 'use.mcols' is TRUE)
Will do.
2) A 'dropMcols' or 'dropmcols' method with signature 'GRanges' that is a wrapper for mcols(x) <- NULL
How about setMcols(), which is more general than dropmcols()? Thanks, H.
If I can be of help in providing a patch for this, please let me know. Best wishes Julian On 05.05.2014 23:29, Herv? Pag?s wrote:
On 05/05/2014 02:12 PM, Cook, Malcolm wrote:
On 05/05/2014 01:00 PM, Cook, Malcolm wrote:
>> Wondering, >> >> Is it too off the beaten track to expect >> >> `mcols<-`(x,NULL)
>
> > args(`mcols<-`)
> function (x, ..., value) > >Arguments after the ellipsis must be named: > > `mcols<-`(x, value=NULL)
Herve - Great - of course - so - does this not provide the means requested by the original poster?
I think Tim also wanted 'x' to be downgraded to a GRanges instance, like Julian's grangesPlain() does. We could use granges() for that. Deciding of an idiom that can be used inline for just dropping the mcols would be good too. `mcols<-`(x, value=NULL) is a little bit tricky, ugly, and error prone as you noticed. These are probably enough reasons for not choosing it as *the* idiom. Its only advantage is that it doesn't introduce a new symbol. H.
> >Nothing we can do about this. > >Cheers, >H. >
>> >> to work? >> >> hint: it does not >>
>> >-----Original Message----- >> >From: bioc-devel-bounces at r-project.org
[mailto:bioc-devel-bounces at r-project.org] On Behalf Of Herv? Pag?s
>> >Sent: Monday, May 05, 2014 1:28 PM >> >To: Kasper Daniel Hansen; Michael Lawrence >> >Cc: Johnston, Jeffrey; ttriche at usc.edu;
bioc-devel at r-project.org; bioconductor at r-project.org
>> >Subject: Re: [Bioc-devel] [BioC] granges() method for
GenomicRanges objects akin to ranges()...
>> >
>> >Hi,
>> >
>> >I have no problem using granges() for that. Just to clarify:
>> > (a) it would propagate the names()
>> > (b) it would drop the metadata()
>> > (c) the mcols() would propagate only if 'use.mcols=TRUE' was
>> > specified ('use.mcols' is FALSE by default)
>> > (d) it would return a GRanges *instance* i.e. input object
'x'
>> > would be downgraded to GRanges if it extends GRanges >> > >> >@Kasper: granges() on SummarizedExperiment ignores the
'use.mcols'
>> >arg and always propagates the mcols. Alternatively you can use
rowData()
>> >which also propagates the mcols. granges() is actually just an
alias
>> >for rowData() on SummarizedExperiment objects. >> > >> >H. >> > >> > >> >On 05/05/2014 10:31 AM, Kasper Daniel Hansen wrote:
>> >> I agree with Michael on this. >> >> >> >> I can see why, in some usage cases, granges() is convenient
to have with
>> >> use.mcols=FALSE (which seems to have been added in the
latest release).
>> >> But in my usage of granges(), where I call granges() on
objects like
>> >> SummarizedExperiments and friends, I have been expecting
granges() to give
>> >> me the GRange component of the object. Not a crippled
version of the
>> >> GRange component. >> >> >> >> This is - to me - very counter intuitive and I wish I had
seen this
>> >> earlier. It is particular frustrating that this default is
part of the
>> >> generic. >> >> >> >> Best, >> >> Kasper >> >> >> >> >> >> On Mon, May 5, 2014 at 12:11 PM, Michael Lawrence
<lawrence.michael at gene.com
>> >>> wrote:
>> >>
>> >>> In my opinion, granges() is not very clear as to the
intent. The mcols are
>> >>> part of the GRanges, so why would calling granges() drop
them? I think we
>> >>> want something similar to unclass(), unname(), etc. This
why I suggested
>> >>> dropmcols(). >> >>> >> >>> >> >>> >> >>> >> >>> On Mon, May 5, 2014 at 8:17 AM, Tim Triche, Jr.
<tim.triche at gmail.com
>> >>>> wrote:
>> >>>
>> >>>> That's exactly what I was after -- the generic is already
defined, so why
>> >>>> not use it? >> >>>> >> >>>> --t >> >>>>
>> >>>>> On May 5, 2014, at 7:42 AM, Julian Gehring
<julian.gehring at embl.de>
>> >>>> wrote:
>> >>>>> >> >>>>> Hi, >> >>>>>
>> >>>>>> On 05.05.2014 16:22, Martin Morgan wrote: >> >>>>>> generalize as setMcols, like setNames? setMcols(x, NULL)
>> >>>>> >> >>>>> How about Tim's original suggestion, to add a 'granges'
method that
>> >>>> works on a 'GRanges' input? The current definition
>> >>>>> >> >>>>> granges(x, use.mcols=FALSE, ...) >> >>>>> >> >>>>> seem suited for this. >> >>>>> >> >>>>> Best wishes >> >>>>> Julian
>> >>>>
>> >>> >> >>> [[alternative HTML version deleted]] >> >>> >> >>> _______________________________________________ >> >>> Bioc-devel at r-project.org mailing list >> >>> https://stat.ethz.ch/mailman/listinfo/bioc-devel >> >>>
>> >> >> >> [[alternative HTML version deleted]] >> >> >> >> _______________________________________________ >> >> Bioc-devel at r-project.org mailing list >> >> https://stat.ethz.ch/mailman/listinfo/bioc-devel >> >>
>> > >> >-- >> >Herv? Pag?s >> > >> >Program in Computational Biology >> >Division of Public Health Sciences >> >Fred Hutchinson Cancer Research Center >> >1100 Fairview Ave. N, M1-B514 >> >P.O. Box 19024 >> >Seattle, WA 98109-1024 >> > >> >E-mail: hpages at fhcrc.org >> >Phone: (206) 667-5791 >> >Fax: (206) 667-1319 >> > >> >_______________________________________________ >> >Bioc-devel at r-project.org mailing list >> >https://stat.ethz.ch/mailman/listinfo/bioc-devel
>>
> >-- >Herv? Pag?s > >Program in Computational Biology >Division of Public Health Sciences >Fred Hutchinson Cancer Research Center >1100 Fairview Ave. N, M1-B514 >P.O. Box 19024 >Seattle, WA 98109-1024 > >E-mail: hpages at fhcrc.org >Phone: (206) 667-5791 >Fax: (206) 667-1319
Herv? Pag?s Program in Computational Biology Division of Public Health Sciences Fred Hutchinson Cancer Research Center 1100 Fairview Ave. N, M1-B514 P.O. Box 19024 Seattle, WA 98109-1024 E-mail: hpages at fhcrc.org Phone: (206) 667-5791 Fax: (206) 667-1319