Should be possible for the annotations to be of any type, as long as they
satisfy a simple contract of NROW() and 2D "[". Then, you could have a
DataFrame, GRanges, or whatever in there. But it would be nice to have a
special class for the container with range information. The contract for
the rang
There are some nice similarities in these new imaginary types. A
"GRangesFrame" is a list of dimensionally identical things (columns) and
some row meta-data (the GRanges). The SE-like object is similarly a list
of dimensionally like things (matrices, RleDataFrames, BigMatrix objects,
HDF5-backed
This.
It would be damned near perfect as a return value for assays coming out of
an object that held several such assays at several time points in a
population, where there are both assay-wise and covariate-wise "holes" that
could nonetheless be usefully imputed across assays.
Statistics is the
>
>
>
> I still think GRanges should be a subclass of DataFrame,
>> which would make this easy, but I don't seem to be winning that argument.
>>
>
> Just impossible. As Michael mentioned back in November, they have
> conflicting APIs.
Maybe a new "GRangesFrame" that is a DataFrame and holds a GR
On 03/03/2015 03:06 PM, Peter Haverty wrote:
I'd like to see a basic class that takes a DataFrame and a sub-class that
takes a GRanges.
Yes.
I still think GRanges should be a subclass of DataFrame,
which would make this easy, but I don't seem to be winning that argument.
Just impossible. As
I'd like to see a basic class that takes a DataFrame and a sub-class that
takes a GRanges. I still think GRanges should be a subclass of DataFrame,
which would make this easy, but I don't seem to be winning that argument.
While the hood is up, can we try some different names?
SummarizedExperiment
Seems like rowData could be made to work universallly through coercion.
rowRanges would not, however, and one would like a convenient mechanism to
condition on whether range information is available. One way is to
introduce a new class and rely on dispatch. But that adds complexity.
On Tue, Mar 3,
Jim et al.,
Why have two accessors (rowRanges, rowData), each of which are less
flexible than the underlying structure and thus will fail (return NULL? or
GRanges()/DataFrame() ?) in some proportion of valid objects?
~G
On Tue, Mar 3, 2015 at 2:37 PM, Jim Hester wrote:
> Motivated by the discu
Motivated by the discussion thread from November (https://stat.ethz.ch/
pipermail/bioc-devel/2014-November/006686.html) the Bioconductor core team
is planning on making changes to the SummarizedExperiment class. Our end
goal is to allow the @rowData slot to become more flexible and hold either
a D
