[BioC] v is for values()

[Hervé Pagès]

On 05/11/2012 12:31 PM, Tim Triche, Jr. wrote:
> back to emd() or dat() or some such then?

or metavals(), metaVals(), mvals(), mVals(), mv(), metacols(),
metaCols(), mcols(), mCols(), mc(), ...

I would back up for emd(), looks to similar to end().

H.

>
> 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.
>
>
>
> On Fri, May 11, 2012 at 12:10 PM, Hervé Pagès <hpages at fhcrc.org
> <mailto: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 <mailto: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
>             <mailto:mailinglist.honeypot at gmail.com>__>  wrote:
>
>                 On Thu, May 10, 2012 at 6:10 PM, Tim Triche,
>                 Jr.<tim.triche at gmail.com <mailto: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 <mailto: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 <mailto:hpages at fhcrc.org>
>     Phone: (206) 667-5791 <tel:%28206%29%20667-5791>
>     Fax: (206) 667-1319 <tel:%28206%29%20667-1319>
>
>
>
>
> --
> /A model is a lie that helps you see the truth./
> /
> /
> Howard Skipper
> <http://cancerres.aacrjournals.org/content/31/9/1173.full.pdf>
>


-- 
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