What he said
This doesn't make any sense from an API perspective. When would a user ever
expect to see unnamed assay matrices?
--t
> On Mar 12, 2015, at 7:46 AM, Kasper Daniel Hansen
> <kasperdanielhan...@gmail.com> wrote:
>
> allowing positional matching strikes me as being far too fragile.
> Depending on the actual implementation, it may not even be clear there is
> an order of the assays.
>
> On Wed, Mar 11, 2015 at 2:45 PM, Valerie Obenchain <voben...@fredhutch.org>
> wrote:
>
>> Hi,
>>
>> After talking with others the vote was against enforcing names on assays()
>> and for positional matching if all names are NULL. A mixture of names and
>> NULL throws an error.
>>
>> example(SummarizedExperiment)
>>
>> ## all named
>>> se2 = se1
>>> assays(cbind(se1, se2))
>> List of length 1
>> names(1): counts
>>
>> ## mixture of names and NULL -> error
>>> names(assays(se1)) = NULL
>>> assays(cbind(se1, se2))
>> Error in assays(cbind(se1, se2)) :
>> error in evaluating the argument 'x' in selecting a method for function
>> 'assays': Error in .bind.arrays(args, cbind, "assays") :
>> elements in ‘assays’ must have the same names
>>
>> ## all NULL -> positional matching
>>> names(assays(se2)) = NULL
>>> assays(cbind(se1, se2))
>> List of length 1
>>
>> If we find common use cases where positional matching is needed with a
>> mixture of names and NULL we can always relax this constraint.
>>
>> Changes are in 1.19.46.
>>
>> Valerie
>>
>>
>>
>>
>>> On 03/06/2015 08:20 AM, Valerie Obenchain wrote:
>>>
>>> Hi Aaron,
>>>
>>> Thanks for catching this.
>>>
>>> I favor enforcing names in 'assays'. Combining by position alone is too
>>> dangerous. I'm thinking of the VCF class where the genome information is
>>> stored in 'assays' and the fields are rarely in the same order.
>>>
>>> Looks like we also need a more informative error message when names
>>> don't match.
>>>
>>>> assays(se1)
>>> List of length 1
>>> names(1): counts1
>>>
>>>> assays(se2)
>>> List of length 1
>>> names(1): counts2
>>>
>>>> cbind(se1, se2)
>>> Error in sQuote(accessorName) :
>>> argument "accessorName" is missing, with no default
>>>
>>>
>>> Valerie
>>>
>>>
>>>> On 03/05/2015 11:09 PM, Aaron Lun wrote:
>>>>
>>>> Dear all,
>>>>
>>>> I stumbled upon some unexpected behaviour with cbind'ing
>>>> SummarizedExperiment objects with unnamed assays:
>>>>
>>>> require(GenomicRanges)
>>>>> nrows <- 5; ncols <- 4
>>>>> counts <- matrix(runif(nrows * ncols, 1, 1e4), nrows)
>>>>> rowData <- GRanges("chr1", IRanges(1:nrows, 1:nrows))
>>>>> colData <- DataFrame(Treatment=1:ncols, row.names=LETTERS[1:ncols])
>>>>> sset <- SummarizedExperiment(counts, rowData=rowData, colData=colData)
>>>>> sset
>>>> class: SummarizedExperiment
>>>> dim: 5 4
>>>> exptData(0):
>>>> assays(1): ''
>>>> rownames: NULL
>>>> rowData metadata column names(0):
>>>> colnames(4): A B C D
>>>> colData names(1): Treatment
>>>>
>>>>>
>>>>> cbind(sset, sset)
>>>> dim: 5 8
>>>> exptData(0):
>>>> assays(0):
>>>> rownames: NULL
>>>> rowData metadata column names(0):
>>>> colnames(8): A B ... C1 D1
>>>> colData names(1): Treatment
>>>>
>>>> Upon cbind'ing, the assays in the SE object are lost. I think this is
>>>> due to the fact that the cbind code matches up assays by their names.
>>>> Thus, if there are no names, the code assumes that there are no assays.
>>>>
>>>> I guess this could be prevented by enforcing naming of assays in the
>>>> SummarizedExperiment constructor. Or, the binding code could be modified
>>>> to work positionally when there are no assay names, e.g., by cbind'ing
>>>> the first assays across all SE objects, then the second assays, etc.
>>>>
>>>> Any thoughts?
>>>>
>>>> Regards,
>>>>
>>>> Aaron
>>>>
>>>> sessionInfo()
>>>> R Under development (unstable) (2014-12-14 r67167)
>>>> Platform: x86_64-unknown-linux-gnu (64-bit)
>>>>
>>>> locale:
>>>> [1] LC_CTYPE=en_US.UTF-8 LC_NUMERIC=C
>>>> [3] LC_TIME=en_US.UTF-8 LC_COLLATE=en_US.UTF-8
>>>> [5] LC_MONETARY=en_US.UTF-8 LC_MESSAGES=en_US.UTF-8
>>>> [7] LC_PAPER=en_US.UTF-8 LC_NAME=C
>>>> [9] LC_ADDRESS=C LC_TELEPHONE=C
>>>> [11] LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=C
>>>>
>>>> attached base packages:
>>>> [1] stats4 parallel stats graphics grDevices utils
>>>> datasets
>>>> [8] methods base
>>>>
>>>> other attached packages:
>>>> [1] GenomicRanges_1.19.42 GenomeInfoDb_1.3.13 IRanges_2.1.41
>>>> [4] S4Vectors_0.5.21 BiocGenerics_0.13.6
>>>>
>>>> loaded via a namespace (and not attached):
>>>> [1] XVector_0.7.4
>>>>
>>>>
>>>> ______________________________________________________________________
>>>> The information in this email is confidential and inte...{{dropped:15}}
>>>
>>> _______________________________________________
>>> 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, Seattle, WA 98109
>>
>> Email: voben...@fredhutch.org
>> Phone: (206) 667-3158
>>
>>
>> _______________________________________________
>> 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
_______________________________________________
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel
