[Bioc-devel] [BioC] granges() method for GenomicRanges objects akin to ranges()...

Why not just do

mcols(gr) <- NULL

It's way more obvious than granges(gr). And that should happen virtually
instantaneously in R 3.1, regardless of the length.




On Sun, May 4, 2014 at 3:55 PM, Tim Triche, Jr. <tim.triche at gmail.com>wrote:

Right, what I was wondering however is whether it's possible not to create
or modify the object at all, but rather access only the necessary bits.

It seems like a slightly different structure that puts all the location in
one place (say @granges) and the metadata in another (as it presently is)
might be handy to avoid this hoohah.  That's rather a larger change.

--t

On May 4, 2014, at 3:23 PM, "Johnston, Jeffrey" <jjj at stowers.org> wrote:

On May 4, 2014, at 3:50 PM, Tim Triche, Jr. <tim.triche at gmail.com>

wrote:

I wanted something to extract @ranges from a GRanges object along with

its

@seqnames, @strand, and @seqinfo.  Essentially, everything but the

mcols.

Does this make sense?  Is there a lighter-weight way to avoid any

copying

in-flight?


setMethod("granges", "GRanges", function(x) {
         GRanges(seqnames=seqnames(x),
                 ranges=ranges(x),
                 strand=strand(x),
                 seqinfo=seqinfo(x))
})


The fact that I'm constructing an entire new GRanges makes me a little
queasy... that said, it has turned out to be useful when I just want a
short list of locations, as for debugging plotting functions, profile
plots, or what have you.

Perhaps just this:

setMethod("granges", "GRanges", function(x) {
  mcols(x) <- NULL
  x
})

	[[alternative HTML version deleted]]

On May 5, 2014, at 1:25 AM, Julian Gehring <julian.gehring at embl.de> wrote:

Hi Tim,

I was looking for a similar function a while ago, and created the 'grangesPlain' function in 'SomaticSignatures':

grangesPlain <-
function (x)
{
   mcols(x) = NULL
   x = as(x, "GRanges")
   return(x)
}

It removes the metadata columns, as Michael described.  Further, it performs an explicit conversion to a 'GRanges' object - in case that 'x' has a derived class like a 'VRanges'.

The main motivation for an extra function is that you can use it inline, e.g

resize(sort(grangesPlain(x)), ...)

works.  It would be great to have such functionality as part of the bioc core.

Best wishes
Julian

On 05.05.2014 01:56, Michael Lawrence wrote:
Why not just do

mcols(gr) <- NULL

It's way more obvious than granges(gr). And that should happen virtually
instantaneously in R 3.1, regardless of the length.




On Sun, May 4, 2014 at 3:55 PM, Tim Triche, Jr. <tim.triche at gmail.com>wrote:

Right, what I was wondering however is whether it's possible not to create
or modify the object at all, but rather access only the necessary bits.

It seems like a slightly different structure that puts all the location in
one place (say @granges) and the metadata in another (as it presently is)
might be handy to avoid this hoohah.  That's rather a larger change.

--t

On May 4, 2014, at 3:23 PM, "Johnston, Jeffrey" <jjj at stowers.org> wrote:

On May 4, 2014, at 3:50 PM, Tim Triche, Jr. <tim.triche at gmail.com>

wrote:

I wanted something to extract @ranges from a GRanges object along with

its

@seqnames, @strand, and @seqinfo.  Essentially, everything but the

mcols.

Does this make sense?  Is there a lighter-weight way to avoid any

copying

in-flight?


setMethod("granges", "GRanges", function(x) {
        GRanges(seqnames=seqnames(x),
                ranges=ranges(x),
                strand=strand(x),
                seqinfo=seqinfo(x))
})


The fact that I'm constructing an entire new GRanges makes me a little
queasy... that said, it has turned out to be useful when I just want a
short list of locations, as for debugging plotting functions, profile
plots, or what have you.

Perhaps just this:

setMethod("granges", "GRanges", function(x) {
 mcols(x) <- NULL
 x
})

   [[alternative HTML version deleted]]

The in-line usage makes sense. How about dropmcols() or something, at least
for removing the mcols?

On Mon, May 5, 2014 at 1:25 AM, Julian Gehring <julian.gehring at embl.de>wrote:

Hi Tim,

I was looking for a similar function a while ago, and created the
'grangesPlain' function in 'SomaticSignatures':

grangesPlain <-
function (x)
{
     mcols(x) = NULL
     x = as(x, "GRanges")
     return(x)
}

It removes the metadata columns, as Michael described.  Further, it
performs an explicit conversion to a 'GRanges' object - in case that 'x'
has a derived class like a 'VRanges'.

The main motivation for an extra function is that you can use it inline,
e.g

resize(sort(grangesPlain(x)), ...)

works.  It would be great to have such functionality as part of the bioc
core.

Best wishes
Julian



On 05.05.2014 01:56, Michael Lawrence wrote:

Why not just do

mcols(gr) <- NULL

It's way more obvious than granges(gr). And that should happen virtually
instantaneously in R 3.1, regardless of the length.




On Sun, May 4, 2014 at 3:55 PM, Tim Triche, Jr. <tim.triche at gmail.com

wrote:

  Right, what I was wondering however is whether it's possible not to

create
or modify the object at all, but rather access only the necessary bits.

It seems like a slightly different structure that puts all the location
in
one place (say @granges) and the metadata in another (as it presently is)
might be handy to avoid this hoohah.  That's rather a larger change.

--t

  On May 4, 2014, at 3:23 PM, "Johnston, Jeffrey" <jjj at stowers.org>

wrote:


  On May 4, 2014, at 3:50 PM, Tim Triche, Jr. <tim.triche at gmail.com>

wrote:

I wanted something to extract @ranges from a GRanges object along with

its

@seqnames, @strand, and @seqinfo.  Essentially, everything but the

mcols.

Does this make sense?  Is there a lighter-weight way to avoid any

copying

in-flight?

setMethod("granges", "GRanges", function(x) {
          GRanges(seqnames=seqnames(x),
                  ranges=ranges(x),
                  strand=strand(x),
                  seqinfo=seqinfo(x))
})


The fact that I'm constructing an entire new GRanges makes me a little
queasy... that said, it has turned out to be useful when I just want a
short list of locations, as for debugging plotting functions, profile
plots, or what have you.

Perhaps just this:

setMethod("granges", "GRanges", function(x) {
   mcols(x) <- NULL
   x
})

         [[alternative HTML version deleted]]

	[[alternative HTML version deleted]]

generalize as setMcols, like setNames? setMcols(x, NULL)

On May 5, 2014, at 7:42 AM, Julian Gehring <julian.gehring at embl.de> wrote:

Hi,

On 05.05.2014 16:22, Martin Morgan wrote:
generalize as setMcols, like setNames? setMcols(x, NULL)

How about Tim's original suggestion, to add a 'granges' method that works on a 'GRanges' input?  The current definition

granges(x, use.mcols=FALSE, ...)

seem suited for this.

Best wishes
Julian

I agree with Michael on this.

I can see why, in some usage cases, granges() is convenient to have with
use.mcols=FALSE (which seems to have been added in the latest release).
  But in my usage of granges(), where I call granges() on objects like
SummarizedExperiments and friends, I have been expecting granges() to give
me the GRange component of the object.  Not a crippled version of the
GRange component.

This is - to me - very counter intuitive and I wish I had seen this
earlier.  It is particular frustrating that this default is part of the
generic.

Best,
Kasper


On Mon, May 5, 2014 at 12:11 PM, Michael Lawrence <lawrence.michael at gene.com

wrote:

In my opinion, granges() is not very clear as to the intent. The mcols are
part of the GRanges, so why would calling granges() drop them? I think we
want something similar to unclass(), unname(), etc. This why I suggested
dropmcols().




On Mon, May 5, 2014 at 8:17 AM, Tim Triche, Jr. <tim.triche at gmail.com

wrote:

That's exactly what I was after -- the generic is already defined, so why
not use it?

--t

On May 5, 2014, at 7:42 AM, Julian Gehring <julian.gehring at embl.de>

wrote:

Hi,

On 05.05.2014 16:22, Martin Morgan wrote:
generalize as setMcols, like setNames? setMcols(x, NULL)

How about Tim's original suggestion, to add a 'granges' method that

works on a 'GRanges' input?  The current definition

granges(x, use.mcols=FALSE, ...)

seem suited for this.

Best wishes
Julian

         [[alternative HTML version deleted]]

	[[alternative HTML version deleted]]

Wondering,

Is it too off the beaten track to expect

`mcols<-`(x,NULL)

to work?

hint: it does not

  >-----Original Message-----
  >From: bioc-devel-bounces at r-project.org [mailto:bioc-devel-bounces at r-project.org] On Behalf Of Herv? Pag?s
  >Sent: Monday, May 05, 2014 1:28 PM
  >To: Kasper Daniel Hansen; Michael Lawrence
  >Cc: Johnston, Jeffrey; ttriche at usc.edu; bioc-devel at r-project.org; bioconductor at r-project.org
  >Subject: Re: [Bioc-devel] [BioC] granges() method for GenomicRanges objects akin to ranges()...
  >
  >Hi,
  >
  >I have no problem using granges() for that. Just to clarify:
  >   (a) it would propagate the names()
  >   (b) it would drop the metadata()
  >   (c) the mcols() would propagate only if 'use.mcols=TRUE' was
  >       specified ('use.mcols' is FALSE by default)
  >   (d) it would return a GRanges *instance* i.e. input object 'x'
  >       would be downgraded to GRanges if it extends GRanges
  >
  >@Kasper: granges() on SummarizedExperiment ignores the 'use.mcols'
  >arg and always propagates the mcols. Alternatively you can use rowData()
  >which also propagates the mcols. granges() is actually just an alias
  >for rowData() on SummarizedExperiment objects.
  >
  >H.
  >
  >
  >On 05/05/2014 10:31 AM, Kasper Daniel Hansen wrote:

  >> I agree with Michael on this.
  >>
  >> I can see why, in some usage cases, granges() is convenient to have with
  >> use.mcols=FALSE (which seems to have been added in the latest release).
  >>   But in my usage of granges(), where I call granges() on objects like
  >> SummarizedExperiments and friends, I have been expecting granges() to give
  >> me the GRange component of the object.  Not a crippled version of the
  >> GRange component.
  >>
  >> This is - to me - very counter intuitive and I wish I had seen this
  >> earlier.  It is particular frustrating that this default is part of the
  >> generic.
  >>
  >> Best,
  >> Kasper
  >>
  >>
  >> On Mon, May 5, 2014 at 12:11 PM, Michael Lawrence <lawrence.michael at gene.com

  >>> wrote:

  >>

  >>> In my opinion, granges() is not very clear as to the intent. The mcols are
  >>> part of the GRanges, so why would calling granges() drop them? I think we
  >>> want something similar to unclass(), unname(), etc. This why I suggested
  >>> dropmcols().
  >>>
  >>>
  >>>
  >>>
  >>> On Mon, May 5, 2014 at 8:17 AM, Tim Triche, Jr. <tim.triche at gmail.com

  >>>> wrote:

  >>>

  >>>> That's exactly what I was after -- the generic is already defined, so why
  >>>> not use it?
  >>>>
  >>>> --t
  >>>>

  >>>>> On May 5, 2014, at 7:42 AM, Julian Gehring <julian.gehring at embl.de>

  >>>> wrote:

  >>>>>
  >>>>> Hi,
  >>>>>

  >>>>>> On 05.05.2014 16:22, Martin Morgan wrote:
  >>>>>> generalize as setMcols, like setNames? setMcols(x, NULL)

  >>>>>
  >>>>> How about Tim's original suggestion, to add a 'granges' method that

  >>>> works on a 'GRanges' input?  The current definition

  >>>>>
  >>>>> granges(x, use.mcols=FALSE, ...)
  >>>>>
  >>>>> seem suited for this.
  >>>>>
  >>>>> Best wishes
  >>>>> Julian

  >>>>

  >>>
  >>>          [[alternative HTML version deleted]]
  >>>
  >>> _______________________________________________
  >>> Bioc-devel at r-project.org mailing list
  >>> https://stat.ethz.ch/mailman/listinfo/bioc-devel
  >>>

  >>
  >> 	[[alternative HTML version deleted]]
  >>
  >> _______________________________________________
  >> Bioc-devel at r-project.org mailing list
  >> https://stat.ethz.ch/mailman/listinfo/bioc-devel
  >>

  >
  >--
  >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
  >
  >_______________________________________________
  >Bioc-devel at r-project.org mailing list
  >https://stat.ethz.ch/mailman/listinfo/bioc-devel

On 05/05/2014 01:00 PM, Cook, Malcolm wrote:

On 05/05/2014 01:00 PM, Cook, Malcolm wrote:

  >> Wondering,
  >>
  >> Is it too off the beaten track to expect
  >>
  >> `mcols<-`(x,NULL)

  >

  >   > args(`mcols<-`)

  >   function (x, ..., value)
  >
  >Arguments after the ellipsis must be named:
  >
  >   `mcols<-`(x, value=NULL)

Herve - Great - of course - so - does this not provide the means requested by the original poster?

  >
  >Nothing we can do about this.
  >
  >Cheers,
  >H.
  >

  >>
  >> to work?
  >>
  >> hint: it does not
  >>

  >>   >-----Original Message-----
  >>   >From: bioc-devel-bounces at r-project.org [mailto:bioc-devel-bounces at r-project.org] On Behalf Of Herv? Pag?s
  >>   >Sent: Monday, May 05, 2014 1:28 PM
  >>   >To: Kasper Daniel Hansen; Michael Lawrence
  >>   >Cc: Johnston, Jeffrey; ttriche at usc.edu; bioc-devel at r-project.org; bioconductor at r-project.org
  >>   >Subject: Re: [Bioc-devel] [BioC] granges() method for GenomicRanges objects akin to ranges()...
  >>   >
  >>   >Hi,
  >>   >
  >>   >I have no problem using granges() for that. Just to clarify:
  >>   >   (a) it would propagate the names()
  >>   >   (b) it would drop the metadata()
  >>   >   (c) the mcols() would propagate only if 'use.mcols=TRUE' was
  >>   >       specified ('use.mcols' is FALSE by default)
  >>   >   (d) it would return a GRanges *instance* i.e. input object 'x'
  >>   >       would be downgraded to GRanges if it extends GRanges
  >>   >
  >>   >@Kasper: granges() on SummarizedExperiment ignores the 'use.mcols'
  >>   >arg and always propagates the mcols. Alternatively you can use rowData()
  >>   >which also propagates the mcols. granges() is actually just an alias
  >>   >for rowData() on SummarizedExperiment objects.
  >>   >
  >>   >H.
  >>   >
  >>   >
  >>   >On 05/05/2014 10:31 AM, Kasper Daniel Hansen wrote:

  >>   >> I agree with Michael on this.
  >>   >>
  >>   >> I can see why, in some usage cases, granges() is convenient to have with
  >>   >> use.mcols=FALSE (which seems to have been added in the latest release).
  >>   >>   But in my usage of granges(), where I call granges() on objects like
  >>   >> SummarizedExperiments and friends, I have been expecting granges() to give
  >>   >> me the GRange component of the object.  Not a crippled version of the
  >>   >> GRange component.
  >>   >>
  >>   >> This is - to me - very counter intuitive and I wish I had seen this
  >>   >> earlier.  It is particular frustrating that this default is part of the
  >>   >> generic.
  >>   >>
  >>   >> Best,
  >>   >> Kasper
  >>   >>
  >>   >>
  >>   >> On Mon, May 5, 2014 at 12:11 PM, Michael Lawrence <lawrence.michael at gene.com

  >>   >>> wrote:

  >>   >>

  >>   >>> In my opinion, granges() is not very clear as to the intent. The mcols are
  >>   >>> part of the GRanges, so why would calling granges() drop them? I think we
  >>   >>> want something similar to unclass(), unname(), etc. This why I suggested
  >>   >>> dropmcols().
  >>   >>>
  >>   >>>
  >>   >>>
  >>   >>>
  >>   >>> On Mon, May 5, 2014 at 8:17 AM, Tim Triche, Jr. <tim.triche at gmail.com

  >>   >>>> wrote:

  >>   >>>

  >>   >>>> That's exactly what I was after -- the generic is already defined, so why
  >>   >>>> not use it?
  >>   >>>>
  >>   >>>> --t
  >>   >>>>

  >>   >>>>> On May 5, 2014, at 7:42 AM, Julian Gehring <julian.gehring at embl.de>

  >>   >>>> wrote:

  >>   >>>>>
  >>   >>>>> Hi,
  >>   >>>>>

  >>   >>>>>> On 05.05.2014 16:22, Martin Morgan wrote:
  >>   >>>>>> generalize as setMcols, like setNames? setMcols(x, NULL)

  >>   >>>>>
  >>   >>>>> How about Tim's original suggestion, to add a 'granges' method that

  >>   >>>> works on a 'GRanges' input?  The current definition

  >>   >>>>>
  >>   >>>>> granges(x, use.mcols=FALSE, ...)
  >>   >>>>>
  >>   >>>>> seem suited for this.
  >>   >>>>>
  >>   >>>>> Best wishes
  >>   >>>>> Julian

  >>   >>>>

  >>   >>>
  >>   >>>          [[alternative HTML version deleted]]
  >>   >>>
  >>   >>> _______________________________________________
  >>   >>> Bioc-devel at r-project.org mailing list
  >>   >>> https://stat.ethz.ch/mailman/listinfo/bioc-devel
  >>   >>>

  >>   >>
  >>   >> 	[[alternative HTML version deleted]]
  >>   >>
  >>   >> _______________________________________________
  >>   >> Bioc-devel at r-project.org mailing list
  >>   >> https://stat.ethz.ch/mailman/listinfo/bioc-devel
  >>   >>

  >>   >
  >>   >--
  >>   >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
  >>   >
  >>   >_______________________________________________
  >>   >Bioc-devel at r-project.org mailing list
  >>   >https://stat.ethz.ch/mailman/listinfo/bioc-devel

  >>

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

On 05/05/2014 02:12 PM, Cook, Malcolm wrote:

On 05/05/2014 01:00 PM, Cook, Malcolm wrote:

  >> Wondering,
  >>
  >> Is it too off the beaten track to expect
  >>
  >> `mcols<-`(x,NULL)

  >

  >   > args(`mcols<-`)

  >   function (x, ..., value)
  >
  >Arguments after the ellipsis must be named:
  >
  >   `mcols<-`(x, value=NULL)

Herve - Great - of course - so - does this not provide the means
requested by the original poster?

I think Tim also wanted 'x' to be downgraded to a GRanges instance,
like Julian's grangesPlain() does. We could use granges() for that.

Deciding of an idiom that can be used inline for just dropping the
mcols would be good too. `mcols<-`(x, value=NULL) is a little bit
tricky, ugly, and error prone as you noticed. These are probably
enough reasons for not choosing it as *the* idiom. Its only advantage
is that it doesn't introduce a new symbol.

H.

  >
  >Nothing we can do about this.
  >
  >Cheers,
  >H.
  >

  >>
  >> to work?
  >>
  >> hint: it does not
  >>

  >>   >-----Original Message-----
  >>   >From: bioc-devel-bounces at r-project.org

[mailto:bioc-devel-bounces at r-project.org] On Behalf Of Herv? Pag?s

  >>   >Sent: Monday, May 05, 2014 1:28 PM
  >>   >To: Kasper Daniel Hansen; Michael Lawrence
  >>   >Cc: Johnston, Jeffrey; ttriche at usc.edu;

bioc-devel at r-project.org; bioconductor at r-project.org

  >>   >Subject: Re: [Bioc-devel] [BioC] granges() method for

GenomicRanges objects akin to ranges()...

  >>   >
  >>   >Hi,
  >>   >
  >>   >I have no problem using granges() for that. Just to clarify:
  >>   >   (a) it would propagate the names()
  >>   >   (b) it would drop the metadata()
  >>   >   (c) the mcols() would propagate only if 'use.mcols=TRUE' was
  >>   >       specified ('use.mcols' is FALSE by default)
  >>   >   (d) it would return a GRanges *instance* i.e. input object 'x'
  >>   >       would be downgraded to GRanges if it extends GRanges
  >>   >
  >>   >@Kasper: granges() on SummarizedExperiment ignores the

'use.mcols'

  >>   >arg and always propagates the mcols. Alternatively you can use

rowData()

  >>   >which also propagates the mcols. granges() is actually just an

alias

  >>   >for rowData() on SummarizedExperiment objects.
  >>   >
  >>   >H.
  >>   >
  >>   >
  >>   >On 05/05/2014 10:31 AM, Kasper Daniel Hansen wrote:

  >>   >> I agree with Michael on this.
  >>   >>
  >>   >> I can see why, in some usage cases, granges() is convenient

to have with

  >>   >> use.mcols=FALSE (which seems to have been added in the

latest release).

  >>   >>   But in my usage of granges(), where I call granges() on

objects like

  >>   >> SummarizedExperiments and friends, I have been expecting

granges() to give

  >>   >> me the GRange component of the object.  Not a crippled

version of the

  >>   >> GRange component.
  >>   >>
  >>   >> This is - to me - very counter intuitive and I wish I had

seen this

  >>   >> earlier.  It is particular frustrating that this default is

part of the

  >>   >> generic.
  >>   >>
  >>   >> Best,
  >>   >> Kasper
  >>   >>
  >>   >>
  >>   >> On Mon, May 5, 2014 at 12:11 PM, Michael Lawrence

<lawrence.michael at gene.com

  >>   >>> wrote:

  >>   >>

  >>   >>> In my opinion, granges() is not very clear as to the

intent. The mcols are

  >>   >>> part of the GRanges, so why would calling granges() drop

them? I think we

  >>   >>> want something similar to unclass(), unname(), etc. This

why I suggested

  >>   >>> dropmcols().
  >>   >>>
  >>   >>>
  >>   >>>
  >>   >>>
  >>   >>> On Mon, May 5, 2014 at 8:17 AM, Tim Triche, Jr.

<tim.triche at gmail.com

  >>   >>>> wrote:

  >>   >>>

  >>   >>>> That's exactly what I was after -- the generic is already

defined, so why

  >>   >>>> not use it?
  >>   >>>>
  >>   >>>> --t
  >>   >>>>

  >>   >>>>> On May 5, 2014, at 7:42 AM, Julian Gehring

<julian.gehring at embl.de>

  >>   >>>> wrote:

  >>   >>>>>
  >>   >>>>> Hi,
  >>   >>>>>

  >>   >>>>>> On 05.05.2014 16:22, Martin Morgan wrote:
  >>   >>>>>> generalize as setMcols, like setNames? setMcols(x, NULL)

  >>   >>>>>
  >>   >>>>> How about Tim's original suggestion, to add a 'granges'

method that

  >>   >>>> works on a 'GRanges' input?  The current definition

  >>   >>>>>
  >>   >>>>> granges(x, use.mcols=FALSE, ...)
  >>   >>>>>
  >>   >>>>> seem suited for this.
  >>   >>>>>
  >>   >>>>> Best wishes
  >>   >>>>> Julian

  >>   >>>>

  >>   >>>
  >>   >>>          [[alternative HTML version deleted]]
  >>   >>>
  >>   >>> _______________________________________________
  >>   >>> Bioc-devel at r-project.org mailing list
  >>   >>> https://stat.ethz.ch/mailman/listinfo/bioc-devel
  >>   >>>

  >>   >>
  >>   >>     [[alternative HTML version deleted]]
  >>   >>
  >>   >> _______________________________________________
  >>   >> Bioc-devel at r-project.org mailing list
  >>   >> https://stat.ethz.ch/mailman/listinfo/bioc-devel
  >>   >>

  >>   >
  >>   >--
  >>   >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
  >>   >
  >>   >_______________________________________________
  >>   >Bioc-devel at r-project.org mailing list
  >>   >https://stat.ethz.ch/mailman/listinfo/bioc-devel

  >>

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