Yes, you're right! Sorry for the noise. I forgot this was how it
always behaved. All I had to do was change the argument name.
On Wed, Apr 1, 2015 at 3:51 PM, Hervé Pagès hpa...@fredhutch.org wrote:
Hi Michael,
On 04/01/2015 07:17 AM, Michael Love wrote:
I'll retract those last two emails
With GenomicRanges 1.19.48, I'm still having issues with re-naming the
first assay and duplication of memory from my March 9 email. I tried
assayNames- as well. My use case is if I am given a
SummarizedExperiment where the first element is not named counts
(albeit the SE is most likely coming from
Would this code inspired by the release version of GenomicRanges work?
e.g. if I want to add a DataFrame with 10 rows:
names - letters[1:10]
x - relist(GRanges(), PartitioningByEnd(integer(10), names=names))
mcols(x) - DataFrame(foo=1:10)
Then give x to the rowRanges argument of
Some guidance on how to avoid duplication of the matrix for developers
would be greatly appreciated.
Another example of a trouble point, is that if I am given an SE with
an unnamed assay and I need to give the assay a name, this also can
expand the memory used. I had found a solution (which works
On Mon, Mar 9, 2015 at 10:30 AM, Vincent Carey st...@channing.harvard.edu
wrote:
I am glad you are keeping this discussion alive Kasper.
On Mon, Mar 9, 2015 at 10:06 AM, Kasper Daniel Hansen
kasperdanielhan...@gmail.com wrote:
It sounds like the proposed changes are already made. However
On 03/09/2015 07:36 AM, Kasper Daniel Hansen wrote:
On Mon, Mar 9, 2015 at 10:30 AM, Vincent Carey st...@channing.harvard.edu
wrote:
I am glad you are keeping this discussion alive Kasper.
On Mon, Mar 9, 2015 at 10:06 AM, Kasper Daniel Hansen
kasperdanielhan...@gmail.com wrote:
It sounds
On 03/09/2015 07:06 AM, Kasper Daniel Hansen wrote:
It sounds like the proposed changes are already made. However (like
others) I am still a bit mystified why this was necessary. The old version
did allow for a GRanges inside the DataFrame of the rowData, as far as I
recall. So I assume this
On Mar 9, 2015 12:36 PM, Martin Morgan mtmor...@fredhutch.org wrote:
On 03/09/2015 08:07 AM, Michael Love wrote:
Some guidance on how to avoid duplication of the matrix for developers
would be greatly appreciated.
It's unsatisfactory, but using withDimnames=FALSE avoids duplication on
Oh, I don't disagree. Perhaps the two problems can be addressed
simultaneously by
1) deciding on what contracts a multi-assay container can/would demand to
be useful
2) calling it something besides SummarizedExperiment, say,
ExperimentCollection
Then the SE API could stay the same as it is
I think we need to make sure that there are enough benefits of something
like GRangesFrame before we introduce yet another complicated and
overlapping data structure into the framework. Prior to summarization, the
ranges seem primary, after summarization, it may often make sense for them
to be
What complexity? The Nature Methods paper laid it out: for most people,
most of the time, use an SE.
That way, the organization of metadata and covariates is enforced for you,
like an ExpressionSet (another winning data structure) but without its
baggage.
Maybe the Summarized in the name isn't
On Wed, Mar 4, 2015 at 12:01 PM, Robert Castelo robert.cast...@upf.edu
wrote:
some of the goals behind this discussion are IMO similar to the ones for
biocMultiAssay:
https://github.com/vjcitn/biocMultiAssay
maybe Vince can confirm.
It is true that there are connections between the
Michael has a good point. The complexity of the BioC universe of classes
hurts our ability to attract new users. More classes would be a minus there
... but a small set of common, explicit APIs would simplify things.
Rectangular things implement the matrix Interface. :-) Deprecating old
stuff,
My response was meant to address this:
1) fixed-dimension, fixed sample set is a solved problem, and SE is that
solution.
2) multi-assay, holes across samples remains an ugly thorny problem,
maybe needs a new API
So why not keep SE as stable as possible, and dump all the explosive
changes into
some of the goals behind this discussion are IMO similar to the ones for
biocMultiAssay:
https://github.com/vjcitn/biocMultiAssay
maybe Vince can confirm.
robert.
On 03/04/2015 05:16 PM, Tim Triche, Jr. wrote:
Oh, I don't disagree. Perhaps the two problems can be addressed
simultaneously
On 03/04/2015 10:03 AM, Peter Haverty wrote:
Michael has a good point. The complexity of the BioC universe of classes
hurts our ability to attract new users. More classes would be a minus there
... but a small set of common, explicit APIs would simplify things.
Rectangular things implement the
I am a bit concerned about any major alterations to the
SummarizedExperiment API. We have
two papers and plenty of working code that use it in meaningful ways.
Effort required to keep new
formulations back-compatible as well as bug-free has to be weighed
seriously.
I agree that the name is not
May I advocate for 'IndexedDataFrame' or 'IndexedFrame'? 'rowIndices' can
return whatever makes sense (GRanges, or other data structures -thinking
taxonomy for metagenomics for example-). GRangesFrame can inherit from this.
On Wed, Mar 4, 2015 at 3:28 AM, Hervé Pagès hpa...@fredhutch.org wrote:
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 GRanges
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
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
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 james.f.hes...@gmail.com wrote:
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.
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
24 matches
Mail list logo
