Entering edit mode
In continuation of my previous question (https://support.bioconductor.org/p/104597/), I was wondering about the the plans for the new GPos class. I can see it has already been added to vignette, but also that it is currently being actively worked on (along with the underlying IPos object), with one of the updates breaking using the coverage-function on GPos objects.
Both in relation to daily use and package development, would you suggest jumping on board and using the new GPos class right away, or wait a bit until functions are more stable? Is the long term plan still to have GPos extend the GenomicRanges class, keeping all existing functions compatible?
This is fixed in GenomicRanges 1.31.12 (BioC devel only):
https://github.com/Bioconductor/GenomicRanges/commit/27e6939c025029e56ed7dea9e9217dfe06278383
Should become available to BioC devel users via
biocLite()in about 24 hours.Cheers,
H.
Just had look at this again: `coverage` now works on GPos-objects, but the "weight" argument behaves differently. It fails when trying to use a column as weights:
pos_runs <- GRanges(c("chr1", "chr1", "chr2"), IRanges(c(1, 5, 9), c(10, 8, 15))) score(pos_runs) <- 1:length(pos_runs) gpos <- GPos(pos_runs) coverage(gpos) # Works coverage(gpos, weight="score") # FailsIs there any plan of changing this to more closely match the behaviour on GRanges?
No plans to support this in the immediate future. I'm putting this on the TODO list and will get to it after the BioC 3.7 release (scheduled for May 1st). In the mean time, you can work around this by coercing to GRanges first. I recognize that this defeats the purpose of using a GPos object in the first place but note that supporting an arbitrary weight vector when calling
coverage()on a GPos object will blow memory footprint in general (in the worst case scenario the returned object will contain 1 double + 1 integer per position in the GPos object so will be even bigger in memory than the GRanges object obtained by the coercion).H.