Sounds good. One note: if range information becomes optional, it would be
nice if we could mark the availability of the information in the class
hierarchy. Otherwise, it's not easy to enforce a contract (that we can call
range-based methods on a SE) through dispatch. An alternative would be to
drop
On 11/26/2014 12:11 PM, Hervé Pagès wrote:
Hi guys,
I like the idea of separating the row data from the row ranges.
This could be formalized with 2 distinct accessors: rowData() and
rowRanges(). The former would return a DataFrame, and the latter
NULL or a range-based object (GRanges or GRangesL
The two objects have conflicting APIs. For example, 1D extraction indexes
into the ranges for a GRanges, but into the columns for a table. So I would
not recommend multiple inheritance. Instead, define something new with the
semantics you want and use composition. Maybe just a subclass of DataFrame
OK, GRanges as vector that does overlap stuff makes sense, but I think
putting a DataFrame of metadata on that confuses the purpose of the
object. How about a "GRangesTable" that inherits from both GenomicRanges
and DataTable? It would be a DataFrame with a fancy index. The DataFrame
API would m
Hi guys,
I like the idea of separating the row data from the row ranges.
This could be formalized with 2 distinct accessors: rowData() and
rowRanges(). The former would return a DataFrame, and the latter
NULL or a range-based object (GRanges or GRangesList).
I don't think there is the need for an
One thing that’s become apparent working on epivizr is that it may be useful to
think about ‘rowData’ in a SummarizedExperiment as having two distinct
components: row coordinates and row metadata. In the current class rowData is a
‘GenomicRanges’ which contains both coordinates (the ranges) and
GRangesList is very compact, so this would definitely get the job done. But
having an empty range is not the same as a NA, nor does it mean that ranges
are "irrelevant". There are definitely times, especially as we extend
beyond genomics, when we need something more general, as Pete suggests.
As a
so as a simple experiment, I did the following:
library(GenomicRanges)
bar <- matrix(rnorm(100), ncol=10)
colnames(bar) <- as.character(1:10)
rownames(bar) <- letters[1:10]
foo <- SummarizedExperiment(assays=list(bar=bar))
rowData(foo)
## GRangesList object of length 10:
## $a
## GRanges object w
On Wed, Nov 26, 2014 at 9:07 AM, Peter Haverty
wrote:
> Hi all,
>
> I believe there is a strong need for an object that organizes a collection
> of rectangular data (matrices, etc.) with metadata on the rows and
> columns. Can SummarizedExperiment inherit from something simpler that has
> a Data
Hi all,
I believe there is a strong need for an object that organizes a collection
of rectangular data (matrices, etc.) with metadata on the rows and
columns. Can SummarizedExperiment inherit from something simpler that has
a DataFrame as rowData? (I believe GenomicRanges should inherit from
Dat
On 26 November 2014 14:59, Wolfgang Huber wrote:
> A colleague and I are designing a package for quantitative proteomics
> data, and we are debating whether to base it on the
> SummarizedExperiment or the ExpressionSet class.
>
> There is no immediate use for the ranges aspect of
> SummarizedExpe
11 matches
Mail list logo
