Performing set ops with an IRanges object loaded with elementMetadata is like a shotgun, pointing at my foot.
1
0
Entering edit mode
@steve-lianoglou-2771
Last seen 14 months ago
United States
Hi all, I wanted to slice and dice some IRanges object [a] with another [b]: R> a <- new("IRanges" , start = c(6407436L, 6407603L, 6410874L, 6422902L, 6423274L, 6423582L, 6427129L, 6428312L, 6431289L, 6434251L, 6434481L, 6439832L, 6440009L, 6442647L, 6442794L) , width = c(167L, 294L, 193L, 186L, 182L, 131L, 201L, 271L, 450L, 145L, 263L, 79L, 11L, 147L, 798L) , NAMES = NULL , elementMetadata = new("DataFrame" , rownames = NULL , nrows = 15L , elementMetadata = NULL , elementType = "ANY" , metadata = list() , listData = structure(list(exon.anno = c("utr5", "cds", "cds", "cds", "cds", "cds", "cds", "cds", "cds", "cds", "cds", "cds", "cds", "cds", "utr3")), .Names = "exon.anno") ) , elementType = "integer" , metadata = structure(list(tx.start = 6407435L, tx.end = 6443591L, cds.start = 6407603L, cds.end = 6442793L), .Names = c("tx.start", "tx.end", "cds.start", "cds.end")) ) R> b <- new("IRanges" , start = c(6407548L, 6410954L, 6410986L, 6423030L, 6423326L, 6427196L, 6427324L, 6428348L, 6428354L, 6428528L, 6431431L, 6431561L, 6434266L, 6439860L, 6443045L, 6443067L, 6443338L) , width = c(4L, 4L, 4L, 4L, 4L, 4L, 4L, 4L, 4L, 4L, 4L, 4L, 4L, 4L, 4L, 4L, 4L) , NAMES = NULL , elementMetadata = NULL , elementType = "integer" , metadata = list() ) R> setdiff(a, b) Error in .Method(..., deparse.level = deparse.level) : no method for coercing this S4 class to a vector Error in reduce(c(x0, y), drop.empty.ranges = TRUE) : error in evaluating the argument 'x' in selecting a method for function 'reduce' Error in gaps(union(gaps(x, start = start, end = end), y), start = start, : error in evaluating the argument 'x' in selecting a method for function 'gaps' R> intersect(a,b) Error in .Method(..., deparse.level = deparse.level) : no method for coercing this S4 class to a vector Error in reduce(c(x0, y), drop.empty.ranges = TRUE) : error in evaluating the argument 'x' in selecting a method for function 'reduce' Error in gaps(union(gaps(x, start = start, end = end), y), start = start, : error in evaluating the argument 'x' in selecting a method for function 'gaps' This had me puzzled for a while until I realized I had a DataFrame loaded into the elementMetadata of `a` and wondered what the appropriate behavior for the elementMetadata should be if `a` is split into more or less pieces (via setdiff or intersect) -- which I didn't have an answer to. Nuking the elementMetadata first works just fine: R> aa <- a R> elementMetadata(aa) <- NULL R> setdiff(aa, b) ## works I don't know what the answer *really* should be as to what the correct behavior in this situation would be, which I guess could be an interesting discussion ... perhaps the elementMetadata can be split/merged with its associated range, or just dropped all together (perhaps via some explicit parameter in the setdiff, etc. function call?). Anyway, in an effort to skirt that rabbit hole for now, could I ask for a feature request and have IRanges provide a more informative error message when an end user is gunning at their feet w/ this scenario? :-) Thanks, -steve -- Steve Lianoglou Graduate Student: Computational Systems Biology ?| Memorial Sloan-Kettering Cancer Center ?| Weill Medical College of Cornell University Contact Info: http://cbio.mskcc.org/~lianos/contact
Cancer IRanges Cancer IRanges • 1.1k views
ADD COMMENT
0
Entering edit mode
@michael-lawrence-3846
Last seen 2.4 years ago
United States
On Mon, Jul 12, 2010 at 11:05 AM, Steve Lianoglou < mailinglist.honeypot@gmail.com> wrote: > Hi all, > > I wanted to slice and dice some IRanges object [a] with another [b]: > > R> a <- new("IRanges" > , start = c(6407436L, 6407603L, 6410874L, 6422902L, 6423274L, 6423582L, > 6427129L, 6428312L, 6431289L, 6434251L, 6434481L, 6439832L, 6440009L, > 6442647L, 6442794L) > , width = c(167L, 294L, 193L, 186L, 182L, 131L, 201L, 271L, 450L, 145L, > 263L, 79L, 11L, 147L, 798L) > , NAMES = NULL > , elementMetadata = new("DataFrame" > , rownames = NULL > , nrows = 15L > , elementMetadata = NULL > , elementType = "ANY" > , metadata = list() > , listData = structure(list(exon.anno = c("utr5", "cds", "cds", > "cds", "cds", > "cds", "cds", "cds", "cds", "cds", "cds", "cds", "cds", "cds", > "utr3")), .Names = "exon.anno") > ) > , elementType = "integer" > , metadata = structure(list(tx.start = 6407435L, tx.end = > 6443591L, cds.start = 6407603L, > cds.end = 6442793L), .Names = c("tx.start", "tx.end", "cds.start", > "cds.end")) > ) > > R> b <- new("IRanges" > , start = c(6407548L, 6410954L, 6410986L, 6423030L, 6423326L, 6427196L, > 6427324L, 6428348L, 6428354L, 6428528L, 6431431L, 6431561L, 6434266L, > 6439860L, 6443045L, 6443067L, 6443338L) > , width = c(4L, 4L, 4L, 4L, 4L, 4L, 4L, 4L, 4L, 4L, 4L, 4L, 4L, 4L, 4L, > 4L, 4L) > , NAMES = NULL > , elementMetadata = NULL > , elementType = "integer" > , metadata = list() > ) > > R> setdiff(a, b) > Error in .Method(..., deparse.level = deparse.level) : > no method for coercing this S4 class to a vector > Error in reduce(c(x0, y), drop.empty.ranges = TRUE) : > error in evaluating the argument 'x' in selecting a method for > function 'reduce' > Error in gaps(union(gaps(x, start = start, end = end), y), start = start, > : > error in evaluating the argument 'x' in selecting a method for function > 'gaps' > > R> intersect(a,b) > Error in .Method(..., deparse.level = deparse.level) : > no method for coercing this S4 class to a vector > Error in reduce(c(x0, y), drop.empty.ranges = TRUE) : > error in evaluating the argument 'x' in selecting a method for > function 'reduce' > Error in gaps(union(gaps(x, start = start, end = end), y), start = start, > : > error in evaluating the argument 'x' in selecting a method for function > 'gaps' > > This had me puzzled for a while until I realized I had a DataFrame > loaded into the elementMetadata of `a` and wondered what the > appropriate behavior for the elementMetadata should be if `a` is split > into more or less pieces (via setdiff or intersect) -- which I didn't > have an answer to. > > Nuking the elementMetadata first works just fine: > > R> aa <- a > R> elementMetadata(aa) <- NULL > R> setdiff(aa, b) > ## works > > I don't know what the answer *really* should be as to what the correct > behavior in this situation would be, which I guess could be an > interesting discussion ... perhaps the elementMetadata can be > split/merged with its associated range, or just dropped all together > (perhaps via some explicit parameter in the setdiff, etc. function > call?). > > Anyway, in an effort to skirt that rabbit hole for now, could I ask > for a feature request and have IRanges provide a more informative > error message when an end user is gunning at their feet w/ this > scenario? :-) > > I think it would be reasonable to simply drop the metadata, since one is creating an entirely new set of ranges. Might want a warning/message, but I'm not sure if even that is necessary. Just need to document the behavior. Michael Thanks, > -steve > > -- > Steve Lianoglou > Graduate Student: Computational Systems Biology > | Memorial Sloan-Kettering Cancer Center > | Weill Medical College of Cornell University > Contact Info: http://cbio.mskcc.org/~lianos/contact<http: cbio.mskc="" c.org="" %7elianos="" contact=""> > > _______________________________________________ > Bioconductor mailing list > Bioconductor@stat.math.ethz.ch > https://stat.ethz.ch/mailman/listinfo/bioconductor > Search the archives: > http://news.gmane.org/gmane.science.biology.informatics.conductor > [[alternative HTML version deleted]]
ADD COMMENT
0
Entering edit mode
On Mon, Jul 12, 2010 at 2:49 PM, Michael Lawrence <lawrence.michael at="" gene.com=""> wrote: > On Mon, Jul 12, 2010 at 11:05 AM, Steve Lianoglou > <mailinglist.honeypot at="" gmail.com=""> wrote: <snip> >> I don't know what the answer *really* should be as to what the correct >> behavior in this situation would be, which I guess could be an >> interesting discussion ... perhaps the elementMetadata can be >> split/merged with its associated range, or just dropped all together >> (perhaps via some explicit parameter in the setdiff, etc. function >> call?). >> >> Anyway, in an effort to skirt that rabbit hole for now, could I ask >> for a feature request and have IRanges provide a more informative >> error message when an end user is gunning at their feet w/ this >> scenario? :-) >> > > I think it would be reasonable to simply drop the metadata, since one is > creating an entirely new set of ranges. Might want a warning/message, but > I'm not sure if even that is necessary. Just need to document the behavior. I agree that dropping the metadata is sufficient, but (if we were taking a vote) I think I'd have a slight (+0) preference for it to fire off a warning if any of the IRanges objects had metadata that was dropped. -- Steve Lianoglou Graduate Student: Computational Systems Biology ?| Memorial Sloan-Kettering Cancer Center ?| Weill Medical College of Cornell University Contact Info: http://cbio.mskcc.org/~lianos/contact
ADD REPLY
0
Entering edit mode
Hi Steve, Michael, On 07/12/2010 12:01 PM, Steve Lianoglou wrote: > On Mon, Jul 12, 2010 at 2:49 PM, Michael Lawrence > <lawrence.michael at="" gene.com=""> wrote: >> On Mon, Jul 12, 2010 at 11:05 AM, Steve Lianoglou >> <mailinglist.honeypot at="" gmail.com=""> wrote: > <snip> >>> I don't know what the answer *really* should be as to what the correct >>> behavior in this situation would be, which I guess could be an >>> interesting discussion ... perhaps the elementMetadata can be >>> split/merged with its associated range, or just dropped all together >>> (perhaps via some explicit parameter in the setdiff, etc. function >>> call?). >>> >>> Anyway, in an effort to skirt that rabbit hole for now, could I ask >>> for a feature request and have IRanges provide a more informative >>> error message when an end user is gunning at their feet w/ this >>> scenario? :-) >>> >> >> I think it would be reasonable to simply drop the metadata, since one is >> creating an entirely new set of ranges. Might want a warning/message, but >> I'm not sure if even that is necessary. Just need to document the behavior. > > I agree that dropping the metadata is sufficient, but (if we were > taking a vote) I think I'd have a slight (+0) preference for it to > fire off a warning if any of the IRanges objects had metadata that was > dropped. > Sounds reasonable behaviour to me. All the set ops (i.e. gaps(), union(), intersect(), setdiff(), punion(), pintersect(), psetdiff() and pgap()) are currently dropping the names of their args so it makes sense to also drop the metadata and elementMetadata slots. No warning is issued when dropping the names (which is consistent with all the names-dropping function I know) but I think it's OK to issue one when the metadata and elementMetadata slots are dropped. It would not be nice to silently start dropping something that wasn't dropped before. The warning can still be removed later if people find it annoying. H. -- Hervé Pagès Program in Computational Biology Division of Public Health Sciences Fred Hutchinson Cancer Research Center 1100 Fairview Ave. N, M2-B876 P.O. Box 19024 Seattle, WA 98109-1024 E-mail: hpages at fhcrc.org Phone: (206) 667-5791 Fax: (206) 667-1319
ADD REPLY
0
Entering edit mode
Steve, Most of the methods for the IRanges class predate the introduction of the elementMetadata slot and these methods have not been tested when the elementMetadata is not NULL. I have some changes I can check in to BioC 2.7 to the gaps,IRanges-method and union,IRanges,IRanges-method that strips the elementMetadata from the output. Before I check it in, though, I want to survey all the methods to IRanges to see how many other methods need to be modified so I can make the change in one go, rather than in a piecemeal fashion. I'll let you know when my audit is complete and the modifications have been made. Cheers, Patrick On 7/12/10 12:01 PM, Steve Lianoglou wrote: > On Mon, Jul 12, 2010 at 2:49 PM, Michael Lawrence > <lawrence.michael at="" gene.com=""> wrote: > >> On Mon, Jul 12, 2010 at 11:05 AM, Steve Lianoglou >> <mailinglist.honeypot at="" gmail.com=""> wrote: >> > <snip> > >>> I don't know what the answer *really* should be as to what the correct >>> behavior in this situation would be, which I guess could be an >>> interesting discussion ... perhaps the elementMetadata can be >>> split/merged with its associated range, or just dropped all together >>> (perhaps via some explicit parameter in the setdiff, etc. function >>> call?). >>> >>> Anyway, in an effort to skirt that rabbit hole for now, could I ask >>> for a feature request and have IRanges provide a more informative >>> error message when an end user is gunning at their feet w/ this >>> scenario? :-) >>> >>> >> I think it would be reasonable to simply drop the metadata, since one is >> creating an entirely new set of ranges. Might want a warning/message, but >> I'm not sure if even that is necessary. Just need to document the behavior. >> > I agree that dropping the metadata is sufficient, but (if we were > taking a vote) I think I'd have a slight (+0) preference for it to > fire off a warning if any of the IRanges objects had metadata that was > dropped. > >
ADD REPLY

Login before adding your answer.

Traffic: 697 users visited in the last hour
Help About
FAQ
Access RSS
API
Stats

Use of this site constitutes acceptance of our User Agreement and Privacy Policy.

Powered by the version 2.3.6