great, thanks!!
robert.
On 02/25/2015 10:06 PM, Michael Lawrence wrote:
I checked in a fix for the splitting to CompressedVRangesList. The
slowness of creating a SimpleVRangesList is due to the cost of
extracting a VRanges for each sample. Depending your exact use case, it
might be better to pa
I checked in a fix for the splitting to CompressedVRangesList. The slowness
of creating a SimpleVRangesList is due to the cost of extracting a VRanges
for each sample. Depending your exact use case, it might be better to pay
that cost up-front, instead of deferring it to when the user wants to
extr
Yea, I know, just need to get around to that one. Technically, it works,
but it's obviously not ideal.
On Wed, Feb 25, 2015 at 8:52 AM, Gabe Becker wrote:
> Why does splitting a VRanges give a GRangesList with VRanges objects as
> elements? Seems like it should return a VRangesList.
>
> > spl =
Why does splitting a VRanges give a GRangesList with VRanges objects as
elements? Seems like it should return a VRangesList.
> spl = split(vr, sampleNames(vr))
> class(spl)
[1] "GRangesList"
attr(,"package")
[1] "GenomicRanges"
> class(spl[[1]])
[1] "VRanges"
attr(,"package")
[1] "VariantAnnotatio
Construction will take longer; the savings are in the accessing of the
elements. But this seems like too much longer, so I will look into it.
On Wed, Feb 25, 2015 at 8:12 AM, Robert Castelo
wrote:
> my current reason to prefer a CompressedVRangesList object over a
> SimpleVRangesList object is t
my current reason to prefer a CompressedVRangesList object over a
SimpleVRangesList object is that i find one order of magnitude
difference in creation time in each of these classes of objects:
library(VariantAnnotation)
fl <- system.file("extdata", "CEUtrio.vcf.bgz",
package
If you're storing data on a relatively small number of individuals (say,
hundreds), you should use SimpleVRangesList, not CompressedVRangesList.
On Wed, Feb 25, 2015 at 7:10 AM, Robert Castelo
wrote:
> i see you point, the logic i was thinking about is to use a list of
> VRanges objects to hold
i see you point, the logic i was thinking about is to use a list of
VRanges objects to hold separately the variants of multiple individuals,
with one VRanges object per individual.
if i type the name of such a list object on the R shell, having the
GRangesList show method, i feel i do not see
Why not have the SimpleVRangesList be shown like CompressedVRangesList, for
consistency with GRangesList? In other words, the opposite of what you
propose. A strong argument could also be made that a
SimpleGenomicRangesList should be shown like a GRangesList. Unless there is
some aversion to the mo
so, yes, but IMO rather than inheriting the show method from a
GRangesList, i think that the show method for CompressedVRangesList
objects should be inherited from a VRangesList object. right now this is
the situation:
library(VariantAnnotation)
example(VRangesList)
vrl
VRangesList of length 2
I think you might be missing an import. It should inherit the method for
GRangesList.
On Tue, Feb 24, 2015 at 9:53 AM, Robert Castelo
wrote:
> hi,
>
> i'm using the CompressedVRangesList class in VariantFiltering to hold
> variants and their annotations across multiple samples and found that the
hi,
i'm using the CompressedVRangesList class in VariantFiltering to hold
variants and their annotations across multiple samples and found that
there was no show method for this class (unless i'm missing the right
import here) so i made one within VariantFiltering by copying&pasting
from othe
12 matches
Mail list logo
