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
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 SummarizedExperiment, so
that would have to be carried around with NAs,
12 matches
Mail list logo
