I see the argument for separating plotting and computation. I don't see the argument for changing plotPCA to plot. base R has things that work either way; we all know hist(), boxplot() etc etc. And for this specific case there are (good) arguments for the fact that one could envision several plots on a PCA object.
But while I see the argument, by having a common class which all packages should use, it becomes pretty hard to have package specific customization (colors, phenodata etc etc), or it will at least require some thinking. Best, Kasper On Sat, Nov 1, 2014 at 2:21 PM, Michael Love <michaelisaiahl...@gmail.com> wrote: > On Nov 1, 2014 1:29 PM, "Michael Love" <michaelisaiahl...@gmail.com> > wrote: > > > > As far as the proposal of using the plot() function for all plots, I > > think for the biologists who are struggling already to get R going, > > and to figure out what kinds of plots are possible, plotMA (and > > knowing that the help is available at ?plotMA) is just so much simpler > > than the alternative (isn't it ?"plot,MA-method" for S4?). > > > > Scratch that... I forgot that finding help has to be ugly either way. > > > > > > > On Fri, Oct 31, 2014 at 9:10 PM, Michael Lawrence > > <lawrence.mich...@gene.com> wrote: > > > Sure, the ggplot model (returning an abstract representation of a plot, > and > > > then rendering it when requested, i.e., printed) is preferable to the > side > > > effects of base graphics. Unfortunately, plot() implies the side > effect, > > > which motivated the introduction of autoplot() in ggbio, and in fact we > > > used Steve's type= parameter idea in many of the autoplot methods. > While I > > > agree that plotScree() could be preferable to plot(type="scree"), it's > > > still beneficial to have the abstraction, if only for convenience and > to > > > support generic code. Btw, a (S3) pca object already exists: see > ?princomp. > > > > > > Michael > > > > > > On Fri, Oct 31, 2014 at 3:53 PM, Ryan C. Thompson < > r...@thompsonclan.org> > > > wrote: > > > > > >> I'd just like to chime in that regardless of what approach is chosen, > I > > >> definitely would appreciate a way to get the plot data without > actually > > >> making the plot. I often end up reimplementing plots in ggplot so that > I > > >> can easily customize some aspect of them, so in such cases I need a > way to > > >> just get the plot data/coordinates. > > >> > > >> For example, if I have an edgeR DGEList and I want to get the X and Y > > >> coordinates for the MDS plot, I need to do something like: > > >> > > >> dev.new() > > >> mds.coords <- plotMDS(dge) > > >> dev.off() > > >> > > >> which is kind of unfortunate. > > >> > > >> So I guess this is more a reminder to people implementing plots to > also > > >> implement a way to get the plot data. > > >> > > >> -Ryan > > >> > > >> > > >> On Fri 31 Oct 2014 03:43:04 PM PDT, Steve Lianoglou wrote: > > >> > > >>> Hi, > > >>> > > >>> On Fri, Oct 31, 2014 at 2:35 PM, Thomas Lin Pedersen > > >>> <thomas...@gmail.com> wrote: > > >>> > > >>>> With regards to abstraction - I would personally much rather read > and > > >>>> write code that contained plotScores() and plotScree() etc. where > the > > >>>> intend of the code is clearly communicated, instead of relying on a > plot() > > >>>> function whose result is only known from experience. Trying to > squeeze > > >>>> every kind of visual output into the same plot generic seems > artificial and > > >>>> constrained to me. I totally agree on the plotPCA critique on the > other > > >>>> hand... > > >>>> > > >>> > > >>> If we've bought a ticket to ride on Kevin's and Michael's (and > whoever > > >>> else) train of thought, wouldn't plot(pca(x), type='scree') or > > >>> plot(pca(x), type='scores') be the preferred way to go ... for some > > >>> definition of "preferable"? > > >>> > > >>> -steve > > >>> > > >>> > > >>>> Thomas > > >>>> > > >>>> > > >>>> On 31 Oct 2014, at 22:09, Michael Lawrence < > lawrence.mich...@gene.com> > > >>>>> wrote: > > >>>>> > > >>>>> I strongly agree with Kevin's position. plotPCA() represents two > > >>>>> separate concerns in its very name: the computation and the > rendering. > > >>>>> Those need to be separated, at least behind the scenes. The syntax > of > > >>>>> plot(pca(x)) is preferable to plotPCA, because the structure of the > > >>>>> operation is represented by in the expression itself, not just in a > > >>>>> non-computable function name. > > >>>>> > > >>>>> With regard to how a plot,PCA should behave: there is always a > tension > > >>>>> between high-level and low-level APIs. In the end, we need multiple > levels > > >>>>> of abstraction. While high-level APIs sacrifice flexibility, we > need them > > >>>>> because they communicate the high-level *intent* of the user in the > code > > >>>>> itself (self-documenting code), and they enable reusability, which > not only > > >>>>> reduces redudant effort but also ensures consistency. Once our > brains no > > >>>>> longer need to parse low-level code, we can focus our mental power > on > > >>>>> correctness and efficiency. To design a high-level API, one needs > to > > >>>>> carefully analyze user requirements, i.e., the use cases. To choose > the > > >>>>> default behavior, one needs to rate the use cases by their > prevalance, and > > >>>>> by how closely they match the intuition-based expectations of the > user. > > >>>>> > > >>>>> The fact that at least 9 packages are performing such a similar > task > > >>>>> seems to indicate that a common abstraction is warranted, but I am > not sure > > >>>>> if BiocGenerics is the appropriate place. > > >>>>> > > >>>>> Michael > > >>>>> > > >>>>> On Tue, Oct 21, 2014 at 12:54 AM, Thomas Dybdal Pedersen < > > >>>>> thomas...@gmail.com <mailto:thomas...@gmail.com>> wrote: > > >>>>> While I tend to agree with you that PCA is too big an operation to > be > > >>>>> hidden within a plotting function (MDS is an edge-case I would > say), I > > >>>>> can't see how we can ever reach a point where there is only one > generic > > >>>>> plot function. In the case of PCA there is a number of different > plot-types > > >>>>> that can all lay claim to the plot function of a PCA class, for > instance > > >>>>> scoreplot, scatterplot matrix of all scores, biplot, screeplot, > accumulated > > >>>>> R^2 barplot, leverage vs. distance-to-model... (you get the idea). > So while > > >>>>> having some very well-thought out classes for very common result > types such > > >>>>> as PCA, this class would still need a lot of different plot methods > such as > > >>>>> plotScores, plotScree etc (or plot(..., type='score'), but I don't > find > > >>>>> that very appealing). Expanding beyond PCA only muddles the water > even more > > >>>>> - there are very few interesting data structures that only have one > visual > > >>>>> representation to-rule-them-all... > > >>>>> > > >>>>> just my 2c > > >>>>> > > >>>>> best > > >>>>> Thomas > > >>>>> > > >>>>> > > >>>>> Date: Mon, 20 Oct 2014 18:50:48 -0400 > > >>>>>> From: Kevin Coombes <kevin.r.coom...@gmail.com <mailto: > > >>>>>> kevin.r.coom...@gmail.com>> > > >>>>>> > > >>>>>> Well. I have two responses to that. > > >>>>>> > > >>>>>> First, I think it would be a lot better/easier for users if (most) > > >>>>>> developers could make use of the same plot function for "basic" > classes > > >>>>>> like PCA. > > >>>>>> > > >>>>>> Second, if you think the basic PCA plotting routine needs > enhancements, > > >>>>>> you still have two options. On the one hand, you could (as you > said) > > >>>>>> try to convince the maintainer of PCA to add what you want. If > it's > > >>>>>> generally valuable, then he'd probably do it --- and other classes > that > > >>>>>> use it would benefit. On the other hand, if it really is a > special > > >>>>>> enhancement that only makes sense for your class, then you can > derive a > > >>>>>> class from the basic PCA class > > >>>>>> setClass("mySpecialPCA", contains=c("PCA"), *other stuff > here*) > > >>>>>> and implement your own version of the "plot" generic for this > class. > > >>>>>> And you could tweak the "as.PCA" function so it returns an object > of > > >>>>>> the > > >>>>>> mySpecialPCA class. And the user could still just "plot" the > result > > >>>>>> without hacving to care what's happening behind the scenes. > > >>>>>> > > >>>>>> On 10/20/2014 5:59 PM, Michael Love wrote: > > >>>>>> > > >>>>>>> Ah, I see now. Personally, I don't think Bioconductor developers > > >>>>>>> should have to agree on single plotting functions for basic > classes > > >>>>>>> like 'PCA' (because this logic applies equally to the situation > of all > > >>>>>>> Bioconductor developers agreeing on single MA-plot, a single > > >>>>>>> variance-mean plot, etc). I think letting developers define their > > >>>>>>> plotPCA makes contributions easier (I don't have to ask the owner > of > > >>>>>>> plot.PCA to incorporate something), even though it means we have > a > > >>>>>>> growing list of generics. > > >>>>>>> > > >>>>>>> Still you have a good point about splitting computation and > plotting. > > >>>>>>> In practice, we subset the rows so PCA is not laborious. > > >>>>>>> > > >>>>>>> > > >>>>>>> On Mon, Oct 20, 2014 at 5:38 PM, Kevin Coombes > > >>>>>>> <kevin.r.coom...@gmail.com <mailto:kevin.r.coom...@gmail.com> > > >>>>>>> <mailto:kevin.r.coom...@gmail.com <mailto: > kevin.r.coom...@gmail.com>>> > > >>>>>>> wrote: > > >>>>>>> > > >>>>>>> Hi, > > >>>>>>> > > >>>>>>> I don't see how it needs more functions (as long as you can > get > > >>>>>>> developers to agree). Suppose that someone can define a > reusable > > >>>>>>> PCA class. This will contain a single "plot" generic > function, > > >>>>>>> defined once and reused by other classes. The existing > "plotPCA" > > >>>>>>> interface can also be implemented just once, in this class, > as > > >>>>>>> > > >>>>>>> plotPCA <- function(object, ...) plot(as.PCA(object), > ...) > > >>>>>>> > > >>>>>>> This can be exposed to users of your class through > namespaces. > > >>>>>>> Then the only thing a developer needs to implement in his own > > >>>>>>> class is the single "as.PCA" function. And he/she would have > > >>>>>>> already been rquired to implement this as part of the old > > >>>>>>> "plotPCA" function. So it can be extracted from that, and > the > > >>>>>>> developer doesn't have to reimplement the visualization code > from > > >>>>>>> the PCA class. > > >>>>>>> > > >>>>>>> Best, > > >>>>>>> Kevin > > >>>>>>> > > >>>>>>> > > >>>>>>> On 10/20/2014 5:15 PM, davide risso wrote: > > >>>>>>> > > >>>>>>>> Hi Kevin, > > >>>>>>>> > > >>>>>>>> I see your points and I agree (especially for the specific > case > > >>>>>>>> of plotPCA that involves some non trivial computations). > > >>>>>>>> > > >>>>>>>> On the other hand, having a wrapper function that starting > from > > >>>>>>>> the "raw" data gives you a pretty picture (with virtually > zero > > >>>>>>>> effort by the user) using a sensible choice of parameters > that > > >>>>>>>> are more or less OK for RNA-seq data is useful for > practitioners > > >>>>>>>> that just want to look for patterns in the data. > > >>>>>>>> > > >>>>>>>> I guess it would be the same to have a PCA method for each > of the > > >>>>>>>> objects and then using the plot method on those new objects, > but > > >>>>>>>> that would just create a lot more objects and functions than > the > > >>>>>>>> current approach (like Mike was saying). > > >>>>>>>> > > >>>>>>>> Your "as.pca" or "performPCA" approach would be definitely > better > > >>>>>>>> if all the different methods would create objects of the > *same* > > >>>>>>>> PCA class, but since we are talking about different > packages, I > > >>>>>>>> don't know how easy it would be to coordinate. But perhaps > this > > >>>>>>>> is the way we should go. > > >>>>>>>> > > >>>>>>>> Best, > > >>>>>>>> davide > > >>>>>>>> > > >>>>>>>> > > >>>>>>>> > > >>>>>>>> On Mon, Oct 20, 2014 at 1:26 PM, Kevin Coombes > > >>>>>>>> <kevin.r.coom...@gmail.com <mailto: > kevin.r.coom...@gmail.com> > > >>>>>>>> <mailto:kevin.r.coom...@gmail.com <mailto: > kevin.r.coom...@gmail.com>>> > > >>>>>>>> wrote: > > >>>>>>>> > > >>>>>>>> Hi, > > >>>>>>>> > > >>>>>>>> It depends. > > >>>>>>>> > > >>>>>>>> The "traditional" R approach to these matters is that > you (a) > > >>>>>>>> first perform some sort of an analysis and save the > results > > >>>>>>>> as an object and then (b) show or plot what you got. It > is > > >>>>>>>> part (b) that tends to be really generic, and (in my > opinion) > > >>>>>>>> should have really generic names -- like "show" or > "plot" or > > >>>>>>>> "hist" or "image". > > >>>>>>>> > > >>>>>>>> With PCA in particular, you usually have to perform a > bunch > > >>>>>>>> of computations in order to get the principal components > from > > >>>>>>>> some part of the data. As I understand it now, these > > >>>>>>>> computations are performed along the way as part of the > > >>>>>>>> various "plotPCA" functions. The "R way" to do this > would be > > >>>>>>>> something like > > >>>>>>>> pca <- performPCA(mySpecialObject) # or > > >>>>>>>> as.PCA(mySpecialObject) > > >>>>>>>> plot(pca) # to get the scatter plot > > >>>>>>>> This apporach has the user-friendly advantage that you > can > > >>>>>>>> tweak the plot (in terms of colors, symbols, ranges, > titles, > > >>>>>>>> etc) without having to recompute the principal > components > > >>>>>>>> every time. (I often find myself re-plotting the same > PCA > > >>>>>>>> several times, with different colors or symbols for > different > > >>>>>>>> factrors associated with the samples.) In addition, you > could > > >>>>>>>> then also do something like > > >>>>>>>> screeplot(pca) > > >>>>>>>> to get a plot of the percentages of variance explained. > > >>>>>>>> > > >>>>>>>> My own feeling is that if the object doesn't know what > to do > > >>>>>>>> when you tell it to "plot" itself, then you haven't got > the > > >>>>>>>> right abstraction. > > >>>>>>>> > > >>>>>>>> You may still end up needing generics for each kind of > > >>>>>>>> computation you want to perform (PCA, RLE, MA, etc), > which is > > >>>>>>>> why I suggested an "as.PCA" function. After all, "as" > is > > >>>>>>>> already pretty generic. In the long run, l this would > herlp > > >>>>>>>> BioConductor developers, since they wouldn't all have to > > >>>>>>>> reimplement the visualization code; they would just have > to > > >>>>>>>> figure out how to convert their own object into a PCA or > RLE > > >>>>>>>> or MA object. > > >>>>>>>> > > >>>>>>>> And I know that this "plotWhatever" approach is used > > >>>>>>>> elsewhere in BioConductor, and it has always bothered > me. It > > >>>>>>>> just seemed that a post suggesting a new generic > function > > >>>>>>>> provided a reasonable opportunity to point out that > there > > >>>>>>>> might be a better way. > > >>>>>>>> > > >>>>>>>> Best, > > >>>>>>>> Kevin > > >>>>>>>> > > >>>>>>>> PS: My own "ClassDicsovery" package, which is available > from > > >>>>>>>> RForge via > > >>>>>>>> **|install.packages("ClassDiscovery", > > >>>>>>>> repos="http://R-Forge.R-project.org < > > >>>>>>>> http://r-forge.r-project.org/>" > > >>>>>>>> <http://R-Forge.R-project.org < > http://r-forge.r-project.org/ > > >>>>>>>> >>)|** > > >>>>>>>> includes a "SamplePCA" class that does something roughly > > >>>>>>>> similar to this for microarrays. > > >>>>>>>> > > >>>>>>>> PPS (off-topic): The worst offender in base R -- because > it > > >>>>>>>> doesn't use this "typical" approch -- is the "heatmap" > > >>>>>>>> function. Having tried to teach this function in > several > > >>>>>>>> different classes, I have come to the conclusion that it > is > > >>>>>>>> basically unusable by mortals. And I think the problem > is > > >>>>>>>> that it tries to combine too many steps -- clustering > rows, > > >>>>>>>> clustering columns, scaling, visualization -- all in a > single > > >>>>>>>> fiunction > > >>>>>>>> > > >>>>>>>> > > >>>>>>>> On 10/20/2014 3:47 PM, davide risso wrote: > > >>>>>>>> > > >>>>>>>>> Hi Kevin, > > >>>>>>>>> > > >>>>>>>>> I don't agree. In the case of EDASeq (as I suppose it > is the > > >>>>>>>>> case for DESeq/DESeq2) plotting the principal > components of > > >>>>>>>>> the count matrix is only one of possible exploratory > plots > > >>>>>>>>> (RLE plots, MA plots, etc.). > > >>>>>>>>> So, in my opinion, it makes more sense from an object > > >>>>>>>>> oriented point of view to have multiple plotting > methods for > > >>>>>>>>> a single "RNA-seq experiment" object. > > >>>>>>>>> > > >>>>>>>>> In addition, this is the same strategy adopted > elsewhere in > > >>>>>>>>> Bioconductor, e.g., for the plotMA method. > > >>>>>>>>> > > >>>>>>>>> Just my two cents. > > >>>>>>>>> > > >>>>>>>>> Best, > > >>>>>>>>> davide > > >>>>>>>>> > > >>>>>>>>> On Mon, Oct 20, 2014 at 11:30 AM, Kevin Coombes > > >>>>>>>>> <kevin.r.coom...@gmail.com <mailto: > kevin.r.coombes@gmail > . > > >>>>>>>>> com> > > >>>>>>>>> <mailto:kevin.r.coom...@gmail.com <mailto: > > >>>>>>>>> kevin.r.coom...@gmail.com>>> wrote: > > >>>>>>>>> > > >>>>>>>>> I understand that breaking code is a problem, and > that > > >>>>>>>>> is admittedly the main reason not to immediately > adopt > > >>>>>>>>> my suggestion. > > >>>>>>>>> > > >>>>>>>>> But as a purely logical exercise, creating a "PCA" > > >>>>>>>>> object X or something similar and using either > > >>>>>>>>> plot(X) > > >>>>>>>>> or > > >>>>>>>>> plot(as.PCA(mySpecialObject)) > > >>>>>>>>> is a much more sensible use of object-oriented > > >>>>>>>>> programming/design. This requires no new generics > (to > > >>>>>>>>> write or to learn). > > >>>>>>>>> > > >>>>>>>>> And you could use it to transition away from the > current > > >>>>>>>>> system by convincing the various package > maintainers to > > >>>>>>>>> re-implement plotPCA as follows: > > >>>>>>>>> > > >>>>>>>>> plotPCA <- function(object, ...) { > > >>>>>>>>> plot(as.PCA(object), ...) > > >>>>>>>>> } > > >>>>>>>>> > > >>>>>>>>> This would be relatively easy to eventually > deprecate > > >>>>>>>>> and teach users to switch to the alternative. > > >>>>>>>>> > > >>>>>>>>> > > >>>>>>>>> On 10/20/2014 1:07 PM, Michael Love wrote: > > >>>>>>>>> > > >>>>>>>>>> hi Kevin, > > >>>>>>>>>> > > >>>>>>>>>> that would imply there is only one way to plot an > > >>>>>>>>>> object of a given class. Additionally, it would > break a > > >>>>>>>>>> lot of code.? > > >>>>>>>>>> > > >>>>>>>>>> best, > > >>>>>>>>>> > > >>>>>>>>>> Mike > > >>>>>>>>>> > > >>>>>>>>>> On Mon, Oct 20, 2014 at 12:50 PM, Kevin Coombes > > >>>>>>>>>> <kevin.r.coom...@gmail.com <mailto: > > >>>>>>>>>> kevin.r.coom...@gmail.com> > > >>>>>>>>>> <mailto:kevin.r.coom...@gmail.com <mailto: > > >>>>>>>>>> kevin.r.coom...@gmail.com>>> wrote: > > >>>>>>>>>> > > >>>>>>>>>> But shouldn't they all really just be named > "plot" > > >>>>>>>>>> for the appropriate objects? In which case, > there > > >>>>>>>>>> would already be a perfectly good generic.... > > >>>>>>>>>> > > >>>>>>>>>> On Oct 20, 2014 10:27 AM, "Michael Love" > > >>>>>>>>>> <michaelisaiahl...@gmail.com <mailto: > > >>>>>>>>>> michaelisaiahl...@gmail.com> > > >>>>>>>>>> <mailto:michaelisaiahl...@gmail.com <mailto: > > >>>>>>>>>> michaelisaiahl...@gmail.com>>> wrote: > > >>>>>>>>>> > > >>>>>>>>>> I noticed that 'plotPCA' functions are > defined > > >>>>>>>>>> in EDASeq, DESeq2, DESeq, > > >>>>>>>>>> affycoretools, Rcade, facopy, > CopyNumber450k, > > >>>>>>>>>> netresponse, MAIT (maybe > > >>>>>>>>>> more). > > >>>>>>>>>> > > >>>>>>>>>> Sounds like a case for BiocGenerics. > > >>>>>>>>>> > > >>>>>>>>>> best, > > >>>>>>>>>> > > >>>>>>>>>> Mike > > >>>>>>>>>> > > >>>>>>>>>> [[alternative HTML version deleted]] > > >>>>>>>>>> > > >>>>>>>>>> ______________________________ > > >>>>>>>>>> _________________ > > >>>>>>>>>> Bioc-devel@r-project.org <mailto: > > >>>>>>>>>> Bioc-devel@r-project.org> > > >>>>>>>>>> <mailto:Bioc-devel@r-project.org <mailto: > > >>>>>>>>>> Bioc-devel@r-project.org>> mailing list > > >>>>>>>>>> https://stat.ethz.ch/mailman/ > > >>>>>>>>>> listinfo/bioc-devel <https://stat.ethz.ch/mailman/ > > >>>>>>>>>> listinfo/bioc-devel> > > >>>>>>>>>> > > >>>>>>>>>> > > >>>>>>>>>> > > >>>>>>>>> > > >>>>>>>>> > > >>>>>>>>> ------------------------------ > > >>>>>>>>> ------------------------------------------ > > >>>>>>>>> <http://www.avast.com/ <http://www.avast.com/>> > > >>>>>>>>> > > >>>>>>>>> This email is free from viruses and malware because > > >>>>>>>>> avast! Antivirus <http://www.avast.com/ < > > >>>>>>>>> http://www.avast.com/>> protection is > > >>>>>>>>> active. > > >>>>>>>>> > > >>>>>>>>> > > >>>>>>>>> > > >>>>>>>>> > > >>>>>>>>> > > >>>>>>>>> -- > > >>>>>>>>> Davide Risso, PhD > > >>>>>>>>> Post Doctoral Scholar > > >>>>>>>>> Division of Biostatistics > > >>>>>>>>> School of Public Health > > >>>>>>>>> University of California, Berkeley > > >>>>>>>>> 344 Li Ka Shing Center, #3370 > > >>>>>>>>> Berkeley, CA 94720-3370 > > >>>>>>>>> E-mail: davide.ri...@berkeley.edu <mailto: > > >>>>>>>>> davide.ri...@berkeley.edu> > > >>>>>>>>> <mailto:davide.ri...@berkeley.edu <mailto: > > >>>>>>>>> davide.ri...@berkeley.edu>> > > >>>>>>>>> > > >>>>>>>> > > >>>>>>>> > > >>>>>>>> > > >>>>>>>> > ------------------------------------------------------------ > > >>>>>>>> ------------ > > >>>>>>>> <http://www.avast.com/ <http://www.avast.com/>> > > >>>>>>>> > > >>>>>>>> This email is free from viruses and malware because > avast! > > >>>>>>>> Antivirus <http://www.avast.com/ <http://www.avast.com/ > >> > > >>>>>>>> protection is active. > > >>>>>>>> > > >>>>>>>> > > >>>>>>>> > > >>>>>>>> > > >>>>>>>> > > >>>>>>>> -- > > >>>>>>>> Davide Risso, PhD > > >>>>>>>> Post Doctoral Scholar > > >>>>>>>> Division of Biostatistics > > >>>>>>>> School of Public Health > > >>>>>>>> University of California, Berkeley > > >>>>>>>> 344 Li Ka Shing Center, #3370 > > >>>>>>>> Berkeley, CA 94720-3370 > > >>>>>>>> E-mail: davide.ri...@berkeley.edu <mailto: > davide.risso@berkeley. > > >>>>>>>> edu> <mailto:davide.ri...@berkeley.edu <mailto: > > >>>>>>>> davide.ri...@berkeley.edu>> > > >>>>>>>> > > >>>>>>> > > >>>>>>> > > >>>>>>> > > >>>>>>> ------------------------------------------------------------ > > >>>>>>> ------------ > > >>>>>>> <http://www.avast.com/ <http://www.avast.com/>> > > >>>>>>> > > >>>>>>> This email is free from viruses and malware because avast! > > >>>>>>> Antivirus <http://www.avast.com/ <http://www.avast.com/>> > > >>>>>>> protection is active. > > >>>>>>> > > >>>>>>> > > >>>>>>> > > >>>>>>> > > >>>>>> > > >>>>>> > > >>>>>> --- > > >>>>>> This email is free from viruses and malware because avast! > Antivirus > > >>>>>> protection is active. > > >>>>>> > > >>>>>> > > >>>>>> [[alternative HTML version deleted]] > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> ------------------------------ > > >>>>>> > > >>>>>> _______________________________________________ > > >>>>>> Bioc-devel mailing list > > >>>>>> Bioc-devel@r-project.org <mailto:Bioc-devel@r-project.org> > > >>>>>> https://stat.ethz.ch/mailman/listinfo/bioc-devel < > > >>>>>> https://stat.ethz.ch/mailman/listinfo/bioc-devel> > > >>>>>> > > >>>>>> > > >>>>>> End of Bioc-devel Digest, Vol 127, Issue 43 > > >>>>>> ******************************************* > > >>>>>> > > >>>>> > > >>>>> _______________________________________________ > > >>>>> Bioc-devel@r-project.org <mailto:Bioc-devel@r-project.org> mailing > list > > >>>>> https://stat.ethz.ch/mailman/listinfo/bioc-devel < > > >>>>> https://stat.ethz.ch/mailman/listinfo/bioc-devel> > > >>>>> > > >>>>> > > >>>> > > >>>> [[alternative HTML version deleted]] > > >>>> > > >>>> _______________________________________________ > > >>>> Bioc-devel@r-project.org mailing list > > >>>> https://stat.ethz.ch/mailman/listinfo/bioc-devel > > >>>> > > >>> > > >>> > > >>> > > >>> > > > > > > [[alternative HTML version deleted]] > > > > > > _______________________________________________ > > > Bioc-devel@r-project.org mailing list > > > https://stat.ethz.ch/mailman/listinfo/bioc-devel > > [[alternative HTML version deleted]] > > _______________________________________________ > Bioc-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/bioc-devel > [[alternative HTML version deleted]] _______________________________________________ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel