On Mon, Mar 24, 2014 at 11:07 AM, Martin Morgan <mtmorgan@fhcrc.org> wrote:

> On 03/20/2014 06:29 PM, Kasper Daniel Hansen wrote:
>
>> It used to be the case that when a SummarizedExperiment was constructed,
>> dim names was removed from the matrices in assay.  One could then either
>> use
>> (1)  assay(, withDimnames = TRUE)
>> which ensured dim names in the return value, but implied copying of the
>> return object because the dim names had to get added, or
>> (2) assay(, withDimnames = FALSE)
>> which ensured that the return object had no dim names (because they were
>> stripped).
>>
>> It seems in a recent commit (based on log message I am guessing the two
>> copied in at the bottom of the email, dim names are not stripped at
>> construction.  This implies that
>>    assay(, withDimnames = FALSE)
>> returns an object with the dimnames because they are already present in
>> the
>> raw object.
>>
>> Now, my questions are
>> (1) can I depend on this behavior?
>>
>
> yes.
>
>
>  (2) Is there any check that the dimnames which may be present in the 'raw'
>> assay object are in line with what I get from assay(withDimnames = TRUE)
>> or
>> could I imagine getting different dimnames (and not just no dimnames vs
>> with dimnames) depending on withDimnames?
>>
>>
> more structure will be imposed; the dimnames of the overall object will
> agree with the dimnames of the assays.
>
>
>  To get some context, in bsseq I always use withDimnames=FALSE because the
>> assay matrices are big (28M rows), so I want to avoid copying.  But now I
>> get a failed test, since I construct an object with colnames in the assay.
>>   This seems to be an esoteric point, but it has performance implications
>> in
>> my usage.  I don't know what the right design is - I like that renaming
>> things are quick, because it only happens in the colData slot.
>>
>
> I think stripping the dimnames from assays was a mistake -- it saves space
> (but not much compared to the assay data) but causes a performance
> bottleneck in normal use (when the dimnames are copied to the assay data)
> so I think it makes sense to just duplicate / check dimnames. This is the
> direction I'll go in, unless there are other opinions.
>
>
>
Will there be repercussions for serialized SummarizedExperiment instances?
updateObject will be necessary?  Should we be doing/are we doing class
versioning?



>
>> Finally, it seems that the NEWS file in GenomicRanges is no longer
>> maintained.  Is this intentional ? :(
>>
>
> the *Ranges tradition seems to be to update the NEWS files prior to
> release, rather than during development. So for instance
>
> ------------------------------------------------------------------------
> r87773 | hpages@fhcrc.org | 2014-03-24 00:49:50 -0700 (Mon, 24 Mar 2014)
> | 1 line
>
> start to update NEWS file with changes in the upcoming 1.16.0 version
>
>
>
>> Best,
>> Kasper
>>
>>
>> r77404 | mtmorgan@fhcrc.org | 2013-06-11 15:52:25 -0400 (Tue, 11 Jun
>> 2013)
>> | 5 lines
>>
>> relax SummarizedExperiment assays class validity
>>
>> - dim() of length >= 2
>> - does not guarantee functionality; may be altered in the future
>>
>> ------------------------------------------------------------------------
>> r76679 | mtmorgan@fhcrc.org | 2013-05-16 17:12:43 -0400 (Thu, 16 May
>> 2013)
>> | 4 lines
>>
>> more efficient ref class constructor
>>
>> - new empty instance, the update slots
>>
>>         [[alternative HTML version deleted]]
>>
>> _______________________________________________
>> Bioc-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>>
>>
>
> --
> Computational Biology / Fred Hutchinson Cancer Research Center
> 1100 Fairview Ave. N.
> PO Box 19024 Seattle, WA 98109
>
> Location: Arnold Building M1 B861
> Phone: (206) 667-2793
>
>
> _______________________________________________
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>

	[[alternative HTML version deleted]]

