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-boun...@r-project.org
[mailto:bioc-devel-boun...@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; ttri...@usc.edu; bioc-devel@r-project.org;
bioconduc...@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.mich...@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.tri...@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.gehr...@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@r-project.org mailing list
>> >>> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>> >>>
>> >>
>> >> [[alternative HTML version deleted]]
>> >>
>> >> _______________________________________________
>> >> Bioc-devel@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: hpa...@fhcrc.org
>> >Phone: (206) 667-5791
>> >Fax: (206) 667-1319
>> >
>> >_______________________________________________
>> >Bioc-devel@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: hpa...@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: hpa...@fhcrc.org
Phone: (206) 667-5791
Fax: (206) 667-1319
_______________________________________________
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel
