[BioC] v is for values()

[Hervé Pagès]

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
>>>
>>
>>
>>
>> --
>> *A model is a lie that helps you see the truth.*
>> *
>> *
>> Howard Skipper<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
> Search the archives: 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