[BioC] v is for values()

[Kasper Daniel Hansen]

On Fri, May 11, 2012 at 3:31 PM, Tim Triche, Jr. <tim.triche at gmail.com> wrote:
> back to emd() or dat() or some such then?
>
> something shorter than values(foo)$bar would be handy.  I've switched to
> using SummarizedExperiments for everything, so this isn't always as much of
> a big deal as it once was, but for situations like Gviz, where internally
> the code expects a GRanges with lots of stuff in the columns, it gets to be
> a drag to write elementMetadata(foo)$bar all over the place.

I strongly agree with this.  It does not matter at all for package
development, but it is a pain to deal with on the command line, when I
explore data.  A big pain.

Kasper

>
>
>
> On Fri, May 11, 2012 at 12:10 PM, Hervé Pagès <hpages at fhcrc.org> wrote:
>
>> On 05/10/2012 03:22 PM, Tim Triche, Jr. wrote:
>>
>>> Incidentally, due to R's crappy unicode support, the € convention cannot
>>> catch on...
>>> I would have already patched it into GenomicRanges otherwise, just to run
>>> with Herve's 4/1/2012 RFP.
>>>
>>> 'tis a shame, sort of.  After the EU breaks up, it will be a perfectly
>>> good
>>> operator symbol!
>>>
>>
>> The € proposal was actually shortsighted... I heard rumors that
>> our new president wants to get rid of the € key on French keyboards.
>> The Germans don't like the idea.
>>
>> More seriously, values() for accessing the elementMetadata is a
>> misnomer. Here is why: when we say that a vector or Vector 'x'
>> "contains duplicated values", or that "its values are negative",
>> or that "its values are unsorted" etc... or when we say that
>> the 6-th value ('x[6]') is the max, and more generally when we
>> talk about the i-th value in 'x', we refer to the naked 'x[i]'
>> thing i.e. what remains after dropping the names, elementMetadata,
>> and any possible attribute attached to it.
>>
>> More precisely: the comparison between 'x[i]' and 'x[j]' (i.e.
>> the i-th and j-th *values* in 'x') ignores the attributes.
>>
>> For example, the *values* in GRanges object 'gr' are the genomic
>> ranges. Each *value* in 'gr' is a quadruplet:
>>
>>  [seqname, strand, start, end]
>>
>> Any other stuff attached to a genomic range is not part of the
>> value. Comparing 2 *values* in 'gr' is comparing 2 quadruplets
>> i.e. it only looks at the seqname, strand, start, and end.
>>
>> So I'm all for getting rid of values() as an alias for
>> elementMetadata(). If we want something shorter, fine, because
>> it's an opportunity to get rid of it. But not v(), please.
>>
>> Cheers,
>> H.
>>
>>
>>>
>>> On Thu, May 10, 2012 at 3:19 PM, Tim Triche, Jr.<tim.triche at gmail.com>**
>>> wrote:
>>>
>>>  well, the obvious answer is to get rid of the function call :-D
>>>>
>>>> but that rather screws up the semantics of GRangesList so it's a
>>>> nonstarter.
>>>>
>>>>
>>>>
>>>> On Thu, May 10, 2012 at 3:14 PM, Steve Lianoglou<
>>>> mailinglist.honeypot at gmail.com**>  wrote:
>>>>
>>>>  On Thu, May 10, 2012 at 6:10 PM, Tim Triche, Jr.<tim.triche at gmail.com>
>>>>> wrote:
>>>>>
>>>>>> Would anyone be opposed to this?
>>>>>>
>>>>>> I really prefer to have an expression on one line whenever possible,
>>>>>> and
>>>>>> when bolting things together with distanceToNearest and friends,
>>>>>>
>>>>> v(foo)$bar
>>>>>
>>>>>> <- baz is quite nice.
>>>>>>
>>>>>
>>>>> Ironically, gmail broke up your oneliner preference example w/ a line
>>>>> break :-)
>>>>>
>>>>> I'm not sure what type of omen that is for your proposal, but ...
>>>>>
>>>>> --
>>>>> Steve Lianoglou
>>>>> Graduate Student: Computational Systems Biology
>>>>>  | Memorial Sloan-Kettering Cancer Center
>>>>>  | Weill Medical College of Cornell University
>>>>> Contact Info: http://cbio.mskcc.org/~lianos/**contact<http://cbio.mskcc.org/~lianos/contact>
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> *A model is a lie that helps you see the truth.*
>>>> *
>>>> *
>>>> Howard Skipper<http://cancerres.**aacrjournals.org/content/31/9/**
>>>> 1173.full.pdf<http://cancerres.aacrjournals.org/content/31/9/1173.full.pdf>
>>>> >
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>> ______________________________**_________________
>>> Bioconductor mailing list
>>> Bioconductor at r-project.org
>>> https://stat.ethz.ch/mailman/**listinfo/bioconductor<https://stat.ethz.ch/mailman/listinfo/bioconductor>
>>> Search the archives: http://news.gmane.org/gmane.**
>>> science.biology.informatics.**conductor<http://news.gmane.org/gmane.science.biology.informatics.conductor>
>>>
>>
>>
>> --
>> 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: hpages at fhcrc.org
>> Phone:  (206) 667-5791
>> Fax:    (206) 667-1319
>>
>
>
>
> --
> *A model is a lie that helps you see the truth.*
> *
> *
> Howard Skipper<http://cancerres.aacrjournals.org/content/31/9/1173.full.pdf>
>
>        [[alternative HTML version deleted]]
>
>
> _______________________________________________
> Bioconductor mailing list
> Bioconductor at r-project.org
> https://stat.ethz.ch/mailman/listinfo/bioconductor
> Search the archives: http://news.gmane.org/gmane.science.biology.informatics.conductor