v is for values()
1
0
Entering edit mode
Tim Triche ★ 4.2k
@tim-triche-3561
Last seen 4.2 years ago
United States
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. -- *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]]
• 1.2k views
ADD COMMENT •
0
Entering edit mode
@steve-lianoglou-2771
Last seen 21 months ago
United States
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
ADD COMMENT •
0
Entering edit mode
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@gmail.com> wrote: > On Thu, May 10, 2012 at 6:10 PM, Tim Triche, Jr. <tim.triche@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=""> [[alternative HTML version deleted]]
ADD REPLY •
0
Entering edit mode
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! On Thu, May 10, 2012 at 3:19 PM, Tim Triche, Jr. <tim.triche@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@gmail.com> wrote: > >> On Thu, May 10, 2012 at 6:10 PM, Tim Triche, Jr. <tim.triche@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=""> > > -- *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]]
ADD REPLY •
0
Entering edit mode
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
ADD REPLY •
0
Entering edit mode
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. On Fri, May 11, 2012 at 12:10 PM, Hervé Pagès <hpages@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@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@gmail.com**> wrote: >>> >>> On Thu, May 10, 2012 at 6:10 PM, Tim Triche, Jr.<tim.triche@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@r-project.org >> https://stat.ethz.ch/mailman/**listinfo/bioconductor<https: stat.e="" thz.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@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]]
ADD REPLY •
0
Entering edit mode
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
ADD REPLY •
0
Entering edit mode
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: cbi="" o.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="" gman="" e.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
ADD REPLY •
0
Entering edit mode
But honestly tho: > back to emd() or dat() or some such then? The difference between values and emd/dat is 3 characters -- is this really going to make a difference? A one-letter accessor or bust! (or use `$` already! :) But also: Are you accessing the values() alot, or changing/adding to them? I should check, but do the with/within constructs work with DataFrame objects, maybe going that route can help in the tedium? For example, when you're accessing the elementMetadata() often: with(values(gr), { ## do lots of stuff w/ the columns }) or if you want to tack on a bunch of junk to the metadata: values(gr) <- within(values(gr), { ## what ## ever ## return some augmented version of your values() }) You know? -steve -- 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
ADD REPLY •
0
Entering edit mode
Here's another idea -- maybe a bad one, but still. What if we were to make a "BiocInteractive" package and put this kind of stuff in there? You could load the package when you're poking at data interactively, but ensure that your package doesn't Import or Depend on it -- not sure if there is a universal check you can do for that, but perhaps you'd put a warning("Don't import this") on its .onAttach or something. You might even put the dreaded values() / $ thing for GRanges in there, and everyone could have their cake and eat it, too. -steve On Fri, May 11, 2012 at 3:48 PM, Steve Lianoglou <mailinglist.honeypot at="" gmail.com=""> wrote: > But honestly tho: > >> back to emd() or dat() or some such then? > > The difference between values and emd/dat is 3 characters -- is this > really going to make a difference? A one-letter accessor or bust! (or > use `$` already! :) > > But also: > > Are you accessing the values() alot, or changing/adding to them? > > I should check, but do the with/within constructs work with DataFrame > objects, maybe going that route can help in the tedium? > > For example, when you're accessing the elementMetadata() often: > > with(values(gr), { > ?## do lots of stuff w/ the columns > }) > > or if you want to tack on a bunch of junk to the metadata: > > values(gr) <- within(values(gr), { > ?## what > ?## ever > ?## return some augmented version of your values() > }) > > You know? > > -steve > > -- > 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 -- 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
ADD REPLY •
0
Entering edit mode
> What if we were to make a "BiocInteractive" package and put this kind > of stuff in there? Or make a GenomicRanges:::interactive()[1] function that dumps the the "$" and "$<-" (or whatever) function into the global namespace. -steve [1] Notice the 3 ":"s -- 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
ADD REPLY •
0
Entering edit mode
Hi, I have a data matrix with genes as columns and samples as rows. I want to create all possible gene ratios.Is there an elegant and fast way to do it in R? Thanks for any help. best Regards, Som. [[alternative HTML version deleted]]
ADD REPLY •

Login before adding your answer.

Similar Posts
Loading Similar Posts
Traffic: 867 users visited in the last hour
Content Search
Users
Tags
Badges
Help About
FAQ
Access RSS
API
Stats

Use of this site constitutes acceptance of our User Agreement and Privacy Policy.

Powered by the version 2.3.6