Also, keeping just the colnames would be sufficient to put a DataFrame in SE's assays. DataFrames need to have colnames, but can have NULL rownames (right?). BTW, BigMatrix also has the argument "withDimnames" for subsetting. Adding dimnames to ( and copying ) a huge vector takes as much time as pulling that huge vector from an mmapped file, so I made it optional there too.
Pete ____________________ Peter M. Haverty, Ph.D. Genentech, Inc. phave...@gene.com On Tue, Mar 25, 2014 at 9:42 AM, Tim Triche, Jr. <tim.tri...@gmail.com>wrote: > If it makes genosets coercible into SEs then I'm all for the change and > its permanence > > --t > > > On Mar 25, 2014, at 9:31 AM, Peter Haverty <haverty.pe...@gene.com> > wrote: > > > > One benefit of having dimnames on assays would be that one could use > > DataFrames as assays, like in eSet. My genoset class is becoming more > and > > more like SummarizedExperiment. The dimname issues prevent me from > > switching entirely from eSet to SummarizedExperiment. > > > > I think that keeping only one copy of dimnames is a great feature, if a > bit > > dangerous. My typical object has ~6 BigMatrix and/or DataFrame of Rle > > objects as assays, so the rownames actually make up a considerable > portion > > of the object size. (My typical dataset is 2.5M rows by 1k samples). > I've > > been moving towards keeping a single dimnames copy just to improve RData > > load times. > > > > I think that assays should be required to have dimnames when they are > added > > to a SummarizedExperiment. These dimnames should be checked for equality > > with the dimnames of the SE in the setter function. > > > > Perhaps with the recent (R 3.1) improvements in shallow/lazy copying and > > reference counting, adding dimnames to outgoing assays will be less of a > > performance hit. > > > > I also like the compromise I have seen elsewhere, where the colnames are > > always retained on assays, but only one rownames copy is kept. Colnames > > are typically small and getting them wrong often makes for silent, but > > catastrophic errors. > > > > Pete > > > > ____________________ > > Peter M. Haverty, Ph.D. > > Genentech, Inc. > > phave...@gene.com > > > > [[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
