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 Michael mentioned back in November, they have
conflicting APIs.
While the hood is up, can we try some different names?
SummarizedExperiment never seemed like a great fit to me because it doesn't
necessarily contain experiments or summaries thereof. It's a collection of
like-sized rectangular things with metadata on the two dimensions. Maybe
the name could reflect what it holds rather than a common use case?
AnnotatedMatrixList?
We actually need 2 names: 1 for the parent class, 1 for the child. I'm
starting to think that introducing 2 new names would maybe make the
migration a little bit easier, especially since the plan is to move the
"refactored SummarizedExperiment" to its own package. With 2 new names
we can start the new package, implement the 2 new classes in it, and
have the old SummarizedExperiment (in GenomicRanges) and the 2 new
classes peacefully cohabit during the time of the migration.
Cheers,
H.
Anyway, I'm excited to see a version on the way that takes a DataFrame as
rowData. I'm glad you guys are working on that.
Regards,
Pete
____________________
Peter M. Haverty, Ph.D.
Genentech, Inc.
phave...@gene.com
On Tue, Mar 3, 2015 at 2:57 PM, Michael Lawrence <lawrence.mich...@gene.com>
wrote:
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, 2015 at 2:44 PM, Gabe Becker <becker.g...@gene.com> wrote:
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:
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 DataFrame or GRanges type object.
To this end we have currently deprecated the current rowData accessor
in
favor of a rowRanges accessor. This change has resulted in a few
broken
builds in devel, which we are in the process of fixing now. We will
contact any package authors directly if needed for this migration.
The rowData accessor will be deprecated in this release, however
eventually
the plan is to re-purpose this function to serve as an accessor for
DataFrame data on the rows.
Please let us know if you have any questions with the above and if you
need
any assistance with the transition.
[[alternative HTML version deleted]]
_______________________________________________
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel
--
Gabriel Becker, Ph.D
Computational Biologist
Genentech Research
[[alternative HTML version deleted]]
_______________________________________________
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel
[[alternative HTML version deleted]]
_______________________________________________
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel
[[alternative HTML version deleted]]
_______________________________________________
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel
--
Hervé Pagès
Program in Computational Biology
Division of Public Health Sciences
Fred Hutchinson Cancer Research Center
1100 Fairview Ave. N, M1-B514
P.O. Box 19024
Seattle, WA 98109-1024
E-mail: hpa...@fredhutch.org
Phone: (206) 667-5791
Fax: (206) 667-1319
_______________________________________________
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel
