Re: [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-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
Re: [Bioc-devel] [BioC] granges() method for GenomicRanges objects akin to ranges()...
On 07/08/2014 11:29 AM, Michael Lawrence wrote:
On Tue, Jul 8, 2014 at 10:36 AM, Julian Gehring julian.gehr...@embl.de
wrote:
Hi Herve,
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()?
Do you mean a function like:
setMcols - function(x, value = NULL) {
mcols(x) = value
return(x)
}
I'd be fine with this. However, some argued before that setting to NULL
may be counterintuitive for non-advanced users.
Probably best to have both setMcols and dropMcols.
OK. Let's go for both.
Thanks,
H.
Best wishes
Julian
___
Bioconductor mailing list
bioconduc...@r-project.org
https://stat.ethz.ch/mailman/listinfo/bioconductor
Search the archives: http://news.gmane.org/gmane.
science.biology.informatics.conductor
[[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
Re: [Bioc-devel] [BioC] granges() method for GenomicRanges objects akin to ranges()...
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)
2) A 'dropMcols' or 'dropmcols' method with signature 'GRanges' that is
a wrapper for
mcols(x) - NULL
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-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
Re: [Bioc-devel] [BioC] granges() method for GenomicRanges objects akin to ranges()...
Hi Tim,
I was looking for a similar function a while ago, and created the
'grangesPlain' function in 'SomaticSignatures':
grangesPlain -
function (x)
{
mcols(x) = NULL
x = as(x, GRanges)
return(x)
}
It removes the metadata columns, as Michael described. Further, it
performs an explicit conversion to a 'GRanges' object - in case that 'x'
has a derived class like a 'VRanges'.
The main motivation for an extra function is that you can use it inline, e.g
resize(sort(grangesPlain(x)), ...)
works. It would be great to have such functionality as part of the bioc
core.
Best wishes
Julian
On 05.05.2014 01:56, Michael Lawrence wrote:
Why not just do
mcols(gr) - NULL
It's way more obvious than granges(gr). And that should happen virtually
instantaneously in R 3.1, regardless of the length.
On Sun, May 4, 2014 at 3:55 PM, Tim Triche, Jr. tim.tri...@gmail.comwrote:
Right, what I was wondering however is whether it's possible not to create
or modify the object at all, but rather access only the necessary bits.
It seems like a slightly different structure that puts all the location in
one place (say @granges) and the metadata in another (as it presently is)
might be handy to avoid this hoohah. That's rather a larger change.
--t
On May 4, 2014, at 3:23 PM, Johnston, Jeffrey j...@stowers.org wrote:
On May 4, 2014, at 3:50 PM, Tim Triche, Jr. tim.tri...@gmail.com
wrote:
I wanted something to extract @ranges from a GRanges object along with
its
@seqnames, @strand, and @seqinfo. Essentially, everything but the
mcols.
Does this make sense? Is there a lighter-weight way to avoid any
copying
in-flight?
setMethod(granges, GRanges, function(x) {
GRanges(seqnames=seqnames(x),
ranges=ranges(x),
strand=strand(x),
seqinfo=seqinfo(x))
})
The fact that I'm constructing an entire new GRanges makes me a little
queasy... that said, it has turned out to be useful when I just want a
short list of locations, as for debugging plotting functions, profile
plots, or what have you.
Perhaps just this:
setMethod(granges, GRanges, function(x) {
mcols(x) - NULL
x
})
___
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
___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel
Re: [Bioc-devel] [BioC] granges() method for GenomicRanges objects akin to ranges()...
Lovely. Hadn't even thought about the VRanges aspect in a while, but this is
essentially the use case I had as well. Thanks!
--t
On May 5, 2014, at 1:25 AM, Julian Gehring julian.gehr...@embl.de wrote:
Hi Tim,
I was looking for a similar function a while ago, and created the
'grangesPlain' function in 'SomaticSignatures':
grangesPlain -
function (x)
{
mcols(x) = NULL
x = as(x, GRanges)
return(x)
}
It removes the metadata columns, as Michael described. Further, it performs
an explicit conversion to a 'GRanges' object - in case that 'x' has a derived
class like a 'VRanges'.
The main motivation for an extra function is that you can use it inline, e.g
resize(sort(grangesPlain(x)), ...)
works. It would be great to have such functionality as part of the bioc core.
Best wishes
Julian
On 05.05.2014 01:56, Michael Lawrence wrote:
Why not just do
mcols(gr) - NULL
It's way more obvious than granges(gr). And that should happen virtually
instantaneously in R 3.1, regardless of the length.
On Sun, May 4, 2014 at 3:55 PM, Tim Triche, Jr. tim.tri...@gmail.comwrote:
Right, what I was wondering however is whether it's possible not to create
or modify the object at all, but rather access only the necessary bits.
It seems like a slightly different structure that puts all the location in
one place (say @granges) and the metadata in another (as it presently is)
might be handy to avoid this hoohah. That's rather a larger change.
--t
On May 4, 2014, at 3:23 PM, Johnston, Jeffrey j...@stowers.org wrote:
On May 4, 2014, at 3:50 PM, Tim Triche, Jr. tim.tri...@gmail.com
wrote:
I wanted something to extract @ranges from a GRanges object along with
its
@seqnames, @strand, and @seqinfo. Essentially, everything but the
mcols.
Does this make sense? Is there a lighter-weight way to avoid any
copying
in-flight?
setMethod(granges, GRanges, function(x) {
GRanges(seqnames=seqnames(x),
ranges=ranges(x),
strand=strand(x),
seqinfo=seqinfo(x))
})
The fact that I'm constructing an entire new GRanges makes me a little
queasy... that said, it has turned out to be useful when I just want a
short list of locations, as for debugging plotting functions, profile
plots, or what have you.
Perhaps just this:
setMethod(granges, GRanges, function(x) {
mcols(x) - NULL
x
})
___
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
___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel
Re: [Bioc-devel] [BioC] granges() method for GenomicRanges objects akin to ranges()...
The in-line usage makes sense. How about dropmcols() or something, at least
for removing the mcols?
On Mon, May 5, 2014 at 1:25 AM, Julian Gehring julian.gehr...@embl.dewrote:
Hi Tim,
I was looking for a similar function a while ago, and created the
'grangesPlain' function in 'SomaticSignatures':
grangesPlain -
function (x)
{
mcols(x) = NULL
x = as(x, GRanges)
return(x)
}
It removes the metadata columns, as Michael described. Further, it
performs an explicit conversion to a 'GRanges' object - in case that 'x'
has a derived class like a 'VRanges'.
The main motivation for an extra function is that you can use it inline,
e.g
resize(sort(grangesPlain(x)), ...)
works. It would be great to have such functionality as part of the bioc
core.
Best wishes
Julian
On 05.05.2014 01:56, Michael Lawrence wrote:
Why not just do
mcols(gr) - NULL
It's way more obvious than granges(gr). And that should happen virtually
instantaneously in R 3.1, regardless of the length.
On Sun, May 4, 2014 at 3:55 PM, Tim Triche, Jr. tim.tri...@gmail.com
wrote:
Right, what I was wondering however is whether it's possible not to
create
or modify the object at all, but rather access only the necessary bits.
It seems like a slightly different structure that puts all the location
in
one place (say @granges) and the metadata in another (as it presently is)
might be handy to avoid this hoohah. That's rather a larger change.
--t
On May 4, 2014, at 3:23 PM, Johnston, Jeffrey j...@stowers.org
wrote:
On May 4, 2014, at 3:50 PM, Tim Triche, Jr. tim.tri...@gmail.com
wrote:
I wanted something to extract @ranges from a GRanges object along with
its
@seqnames, @strand, and @seqinfo. Essentially, everything but the
mcols.
Does this make sense? Is there a lighter-weight way to avoid any
copying
in-flight?
setMethod(granges, GRanges, function(x) {
GRanges(seqnames=seqnames(x),
ranges=ranges(x),
strand=strand(x),
seqinfo=seqinfo(x))
})
The fact that I'm constructing an entire new GRanges makes me a little
queasy... that said, it has turned out to be useful when I just want a
short list of locations, as for debugging plotting functions, profile
plots, or what have you.
Perhaps just this:
setMethod(granges, GRanges, function(x) {
mcols(x) - NULL
x
})
___
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
[[alternative HTML version deleted]]
___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel
Re: [Bioc-devel] [BioC] granges() method for GenomicRanges objects akin to ranges()...
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 ___ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel
Re: [Bioc-devel] [BioC] granges() method for GenomicRanges objects akin to ranges()...
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.comwrote: 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
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
Re: [Bioc-devel] [BioC] granges() method for GenomicRanges objects akin to ranges()...
Wondering,
Is it too off the beaten track to expect
`mcols-`(x,NULL)
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
___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel
Re: [Bioc-devel] [BioC] granges() method for GenomicRanges objects akin to ranges()...
Hi Malcolm,
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)
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
___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel
Re: [Bioc-devel] [BioC] granges() method for GenomicRanges objects akin to ranges()...
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?
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
___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel
Re: [Bioc-devel] [BioC] granges() method for GenomicRanges objects akin to ranges()...
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
Re: [Bioc-devel] [BioC] granges() method for GenomicRanges objects akin to ranges()...
Right, what I was wondering however is whether it's possible not to create or
modify the object at all, but rather access only the necessary bits.
It seems like a slightly different structure that puts all the location in one
place (say @granges) and the metadata in another (as it presently is) might be
handy to avoid this hoohah. That's rather a larger change.
--t
On May 4, 2014, at 3:23 PM, Johnston, Jeffrey j...@stowers.org wrote:
On May 4, 2014, at 3:50 PM, Tim Triche, Jr. tim.tri...@gmail.com wrote:
I wanted something to extract @ranges from a GRanges object along with its
@seqnames, @strand, and @seqinfo. Essentially, everything but the mcols.
Does this make sense? Is there a lighter-weight way to avoid any copying
in-flight?
setMethod(granges, GRanges, function(x) {
GRanges(seqnames=seqnames(x),
ranges=ranges(x),
strand=strand(x),
seqinfo=seqinfo(x))
})
The fact that I'm constructing an entire new GRanges makes me a little
queasy... that said, it has turned out to be useful when I just want a
short list of locations, as for debugging plotting functions, profile
plots, or what have you.
Perhaps just this:
setMethod(granges, GRanges, function(x) {
mcols(x) - NULL
x
})
___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel
Re: [Bioc-devel] [BioC] granges() method for GenomicRanges objects akin to ranges()...
Why not just do
mcols(gr) - NULL
It's way more obvious than granges(gr). And that should happen virtually
instantaneously in R 3.1, regardless of the length.
On Sun, May 4, 2014 at 3:55 PM, Tim Triche, Jr. tim.tri...@gmail.comwrote:
Right, what I was wondering however is whether it's possible not to create
or modify the object at all, but rather access only the necessary bits.
It seems like a slightly different structure that puts all the location in
one place (say @granges) and the metadata in another (as it presently is)
might be handy to avoid this hoohah. That's rather a larger change.
--t
On May 4, 2014, at 3:23 PM, Johnston, Jeffrey j...@stowers.org wrote:
On May 4, 2014, at 3:50 PM, Tim Triche, Jr. tim.tri...@gmail.com
wrote:
I wanted something to extract @ranges from a GRanges object along with
its
@seqnames, @strand, and @seqinfo. Essentially, everything but the
mcols.
Does this make sense? Is there a lighter-weight way to avoid any
copying
in-flight?
setMethod(granges, GRanges, function(x) {
GRanges(seqnames=seqnames(x),
ranges=ranges(x),
strand=strand(x),
seqinfo=seqinfo(x))
})
The fact that I'm constructing an entire new GRanges makes me a little
queasy... that said, it has turned out to be useful when I just want a
short list of locations, as for debugging plotting functions, profile
plots, or what have you.
Perhaps just this:
setMethod(granges, GRanges, function(x) {
mcols(x) - NULL
x
})
___
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
