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
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,
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
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
On Wed, Nov 26, 2014 at 9:07 AM, Peter Haverty haverty.pe...@gene.com
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
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 with
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 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
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
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
10 matches
Mail list logo