On Tue, Jan 26, 2010 at 10:06 AM, Patrick Aboyoun <paboyoun@fhcrc.org>wrote: > Michael, > Before creating a new class to capture the strandedness of a RangedData > objects, it would be useful to have a list of methods in which strandedness > can be used: > > Inter-interval ops: disjoin, gaps, reduce, range, coverage > Between interval set ops: intersect, setdiff, union, findOverlaps, %in%, > match > > For each of these operations, is strandedness a separate and unique > categorization of the data or are there other categories users would like to > group intervals during these operations? For example, I added a "by" > argument to the reduce method for RangedData because I was in correspondence > with someone who wanted to use both "strand" and "score" columns to match > during the reduction exercise. My instinct is that all the inter- interval > operations could use grouping capabilities and these groupings are fluid > where at one pass you might want to use a "score" column and at another you > would like to ignore that information. So in short, I would argue to not add > any more classes and instead add "by" arguments to all the operations listed > above that could support it and for those between interval set operation > that couldn't support it use all the columns in the RangedData objects and > not just the strand so if you wanted to find the intersection of two > RangedData objects, the entire row of data would have to match and not just > the intervals or the stranded intervals. > > Well this idea has certainly crossed my mind, but it sounds like a big headache. Every element that operates over the ranges will need this argument. Isn't this what the by() function is for? I guess we have implicit iteration, so it is not such a big jump to implicit iteration over transient ragged arrays? I realize the GenomicRanges would need to override every method, which is a pain, but at least it is optimized (at least at the user level) for the special use case. Anyway, I guess this idea has my vote. Lot of work though. Michael > Patrick > > > > Michael Lawrence wrote: > >> It seems that RangedData (with a strand variable) has fallen into this >> role >> within the IRanges framework. At one point, there was a GenomicData >> subclass >> that did allow for special strand options. Unfortunately, the >> GenomicData() >> convenience constructor of RangedData is all that is left of that. So we >> could bring that back. Whatever happened to the proposed GenomeRanges >> package? >> >> Michael >> >> On Mon, Jan 25, 2010 at 11:02 AM, Kasper Daniel Hansen < >> khansen@stat.berkeley.edu> wrote: >> >> >> >>> On Jan 25, 2010, at 12:56 PM, Michael Lawrence wrote: >>> >>> >>> >>>> On Fri, Jan 22, 2010 at 11:41 AM, Robert Castelo < >>>> robert.castelo@upf.edu >>>> wrote: >>>> >>>> >>>> >>>>> dear list, and particularly, the IRanges developers, >>>>> >>>>> i'm using the function findOverlaps from the IRanges package because i >>>>> need to find what stranded genomic intervals from one set (as a >>>>> RangedData object) overlap with what stranded genomic intervals from >>>>> another set (as another RangedData object). the problem is that i don't >>>>> what to consider overlaps between genomic intervals from different >>>>> strands. >>>>> >>>>> i've been looking to the help page of findOverlaps (devel version, see >>>>> my sessionInfo() below) and searched through the BioC mailinglist and >>>>> my >>>>> preliminary conclusion is that such an operation is not yet supported. >>>>> >>>>> i've been thinking of using rdapply to break down the RangedData >>>>> objects >>>>> into spaces and then again by the two strands but the problem is that >>>>> the query and subject indexes resulting of findOverlaps will not match >>>>> the dimension of the original RangedData objects. >>>>> >>>>> so, i'd like to suggest that some option is added to this useful >>>>> function to restrict the overlapping search by strand. of course, if >>>>> this is somehow already implemented and i just missed it, then i'll be >>>>> very grateful if you let me know what function/parameter i should be >>>>> using. >>>>> >>>>> >>>>> >>>>> >>>> Well, IRanges knows nothing about Biology, so a 'strand' option would be >>>> >>>> >>> out >>> >>> >>>> of place, in my opinion. That said, I can think of at least two >>>> >>>> >>> approaches. >>> >>> >>>> 1) Simply filter the results for matches that are the the same strand. >>>> >>>> >>> This >>> >>> >>>> is something as simple as: >>>> result <- findOverlaps(a, b) >>>> mat <- as.matrix(result) >>>> mat <- mat[a$strand[mat[,1L]] == b$strand[mat[,2L]],] >>>> >>>> 2) Out of recognition that we are really treating the two strands as >>>> separate spaces, break down the RangedData into chrom*strand spaces, as >>>> >>>> >>> in: >>> >>> >>>> rd <- RangedData(...) >>>> rd <- do.call(c, split(rd, rd$strand)) >>>> result <- findOverlaps(rd, ...) >>>> ## then maybe eventually go back chromosome spaces >>>> rds <- split(rd, rd$strand) >>>> names(rds[[1]]) <- chromNames >>>> names(rds[[2]]) <- chromNames >>>> rd <- do.call(rbind, rds) >>>> >>>> The second approach would be very convenient if you always want to treat >>>> >>>> >>> the >>> >>> >>>> strands separately. The separation could be specified at construction >>>> >>>> >>> time, >>> >>> >>>> e.g.: >>>> RangedData(ranges, strand, space = interaction(chrom, strand)) >>>> >>>> But in general neither of these are awfully convenient, and I've always >>>> >>>> >>> had >>> >>> >>>> the suspicion that we'd eventually need multiple space variables. Yes, >>>> we >>>> could add some argument to the findOverlaps method for RangedData that >>>> >>>> >>> takes >>> >>> >>>> a vector of variable names for splitting into subspaces, but I think we >>>> would want a more general solution, where the RangedData itself has the >>>> notion of subspaces. This would be a non-trivial change. Would it behave >>>> like a nested list in some ways? >>>> >>>> Hopefully others have better ideas... >>>> >>>> >>> We will need good support for stranded genomic intervals. This is a very >>> important case to handle, and will be even more important in the future >>> where a number of assays will be stranded. We need support for doing >>> operations on such objects, both ignoring strand and not ignoring strand. >>> >>> An example could be that we take (stranded) genome annotation and what to >>> perform a per-chromosome reduce(). Users might want to do a reduce >>> respecting strand information where we would get one IRanges per >>> chromosome >>> * strand or we might want to do a reduce(anno , ignoreStrand = TRUE) >>> which >>> yields one IRanges per chromosome. >>> >>> I agree that the general design might be to allow for any number of >>> nested >>> subspaces, but we do have a very important special case where we know >>> that >>> the second level of nestedness only have two components. I believe a lot >>> of >>> value would be gained from being able to operate easily on such objects. >>> >>> Kasper >>> >>> >> >> [[alternative HTML version deleted]] >> >> >> _______________________________________________ >> 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]]