[Bioc-devel] plotPCA for BiocGenerics

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.coombes at 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.coombes at gmail.com <mailto:kevin.r.coombes at 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.coombes at gmail.com <mailto:kevin.r.coombes at 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>)|**
       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.coombes at gmail.com
       <mailto:kevin.r.coombes at 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.coombes at gmail.com
           <mailto:kevin.r.coombes at 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"
               <michaelisaiahlove at gmail.com
               <mailto:michaelisaiahlove at 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]]

------------------------------------------------------------------------

           <http://www.avast.com/>

           This email is free from viruses and malware because
           avast! Antivirus <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.risso at berkeley.edu
       <mailto:davide.risso at berkeley.edu>

------------------------------------------------------------------------

       <http://www.avast.com/>

       This email is free from viruses and malware because avast!
       Antivirus <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.risso at berkeley.edu <mailto:davide.risso at berkeley.edu

------------------------------------------------------------------------

   <http://www.avast.com/>

   This email is free from viruses and malware because avast!
   Antivirus <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]]



------------------------------

On 31 Oct 2014, at 22:09, Michael Lawrence <lawrence.michael at 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 <thomasp85 at gmail.com <mailto:thomasp85 at 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.coombes at gmail.com <mailto:kevin.r.coombes at 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.coombes at gmail.com <mailto:kevin.r.coombes at gmail.com> <mailto:kevin.r.coombes at gmail.com <mailto:kevin.r.coombes at 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.coombes at gmail.com <mailto:kevin.r.coombes at gmail.com> <mailto:kevin.r.coombes at gmail.com <mailto:kevin.r.coombes at 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.coombes at gmail.com <mailto:kevin.r.coombes at gmail.com>
       <mailto:kevin.r.coombes at gmail.com <mailto:kevin.r.coombes at 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.coombes at gmail.com <mailto:kevin.r.coombes at gmail.com>
           <mailto:kevin.r.coombes at gmail.com <mailto:kevin.r.coombes at 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"
               <michaelisaiahlove at gmail.com <mailto:michaelisaiahlove at gmail.com>
               <mailto:michaelisaiahlove at gmail.com <mailto:michaelisaiahlove at 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]]

           ------------------------------------------------------------------------
           <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.risso at berkeley.edu <mailto:davide.risso at berkeley.edu>
       <mailto:davide.risso at berkeley.edu <mailto:davide.risso at 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.risso at berkeley.edu <mailto:davide.risso at berkeley.edu> <mailto:davide.risso at berkeley.edu <mailto:davide.risso at 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]]



------------------------------

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

Thomas

On 31 Oct 2014, at 22:09, Michael Lawrence <lawrence.michael at 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 <thomasp85 at gmail.com <mailto:thomasp85 at 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.coombes at gmail.com <mailto:kevin.r.coombes at 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.coombes at gmail.com <mailto:kevin.r.coombes at gmail.com> <mailto:kevin.r.coombes at gmail.com <mailto:kevin.r.coombes at 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.coombes at gmail.com <mailto:kevin.r.coombes at gmail.com> <mailto:kevin.r.coombes at gmail.com <mailto:kevin.r.coombes at 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.coombes at gmail.com <mailto:kevin.r.coombes at gmail.com>
       <mailto:kevin.r.coombes at gmail.com <mailto:kevin.r.coombes at 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.coombes at gmail.com <mailto:kevin.r.coombes at gmail.com>
           <mailto:kevin.r.coombes at gmail.com <mailto:kevin.r.coombes at 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"
               <michaelisaiahlove at gmail.com <mailto:michaelisaiahlove at gmail.com>
               <mailto:michaelisaiahlove at gmail.com <mailto:michaelisaiahlove at 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]]

           ------------------------------------------------------------------------
           <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.risso at berkeley.edu <mailto:davide.risso at berkeley.edu>
       <mailto:davide.risso at berkeley.edu <mailto:davide.risso at 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.risso at berkeley.edu <mailto:davide.risso at berkeley.edu> <mailto:davide.risso at berkeley.edu <mailto:davide.risso at 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]]



------------------------------

        [[alternative HTML version deleted]]

Hi,

On Fri, Oct 31, 2014 at 2:35 PM, Thomas Lin Pedersen
<thomasp85 at 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.michael at 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 <thomasp85 at gmail.com <mailto:thomasp85 at 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.coombes at gmail.com <mailto:kevin.r.coombes at 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.coombes at gmail.com <mailto:kevin.r.coombes at gmail.com> <mailto:kevin.r.coombes at gmail.com <mailto:kevin.r.coombes at 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.coombes at gmail.com <mailto:kevin.r.coombes at gmail.com> <mailto:kevin.r.coombes at gmail.com <mailto:kevin.r.coombes at 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.coombes at gmail.com <mailto:kevin.r.coombes at gmail.com>
        <mailto:kevin.r.coombes at gmail.com <mailto:kevin.r.coombes at 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.coombes at gmail.com <mailto:kevin.r.coombes at gmail.com>
            <mailto:kevin.r.coombes at gmail.com <mailto:kevin.r.coombes at 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"
                <michaelisaiahlove at gmail.com <mailto:michaelisaiahlove at gmail.com>
                <mailto:michaelisaiahlove at gmail.com <mailto:michaelisaiahlove at 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]]

            ------------------------------------------------------------------------
            <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.risso at berkeley.edu <mailto:davide.risso at berkeley.edu>
        <mailto:davide.risso at berkeley.edu <mailto:davide.risso at 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.risso at berkeley.edu <mailto:davide.risso at berkeley.edu> <mailto:davide.risso at berkeley.edu <mailto:davide.risso at 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]]



------------------------------

         [[alternative HTML version deleted]]

On 31 Oct 2014, at 23:43, Steve Lianoglou <lianoglou.steve at gene.com> wrote:

Hi,

On Fri, Oct 31, 2014 at 2:35 PM, Thomas Lin Pedersen
<thomasp85 at gmail.com <mailto:thomasp85 at 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.michael at 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 <thomasp85 at gmail.com <mailto:thomasp85 at gmail.com> <mailto:thomasp85 at gmail.com <mailto:thomasp85 at 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.coombes at gmail.com <mailto:kevin.r.coombes at gmail.com> <mailto:kevin.r.coombes at gmail.com <mailto:kevin.r.coombes at 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.coombes at gmail.com <mailto:kevin.r.coombes at gmail.com> <mailto:kevin.r.coombes at gmail.com <mailto:kevin.r.coombes at gmail.com>> <mailto:kevin.r.coombes at gmail.com <mailto:kevin.r.coombes at gmail.com> <mailto:kevin.r.coombes at gmail.com <mailto:kevin.r.coombes at 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.coombes at gmail.com <mailto:kevin.r.coombes at gmail.com> <mailto:kevin.r.coombes at gmail.com <mailto:kevin.r.coombes at gmail.com>> <mailto:kevin.r.coombes at gmail.com <mailto:kevin.r.coombes at gmail.com> <mailto:kevin.r.coombes at gmail.com <mailto:kevin.r.coombes at 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/>>"
      <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.coombes at gmail.com <mailto:kevin.r.coombes at gmail.com> <mailto:kevin.r.coombes at gmail.com <mailto:kevin.r.coombes at gmail.com>>
      <mailto:kevin.r.coombes at gmail.com <mailto:kevin.r.coombes at gmail.com> <mailto:kevin.r.coombes at gmail.com <mailto:kevin.r.coombes at 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.coombes at gmail.com <mailto:kevin.r.coombes at gmail.com> <mailto:kevin.r.coombes at gmail.com <mailto:kevin.r.coombes at gmail.com>>
          <mailto:kevin.r.coombes at gmail.com <mailto:kevin.r.coombes at gmail.com> <mailto:kevin.r.coombes at gmail.com <mailto:kevin.r.coombes at 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"
              <michaelisaiahlove at gmail.com <mailto:michaelisaiahlove at gmail.com> <mailto:michaelisaiahlove at gmail.com <mailto:michaelisaiahlove at gmail.com>>
              <mailto:michaelisaiahlove at gmail.com <mailto:michaelisaiahlove at gmail.com> <mailto:michaelisaiahlove at gmail.com <mailto:michaelisaiahlove at 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]]

          ------------------------------------------------------------------------
          <http://www.avast.com/ <http://www.avast.com/> <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/> <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.risso at berkeley.edu <mailto:davide.risso at berkeley.edu> <mailto:davide.risso at berkeley.edu <mailto:davide.risso at berkeley.edu>>
      <mailto:davide.risso at berkeley.edu <mailto:davide.risso at berkeley.edu> <mailto:davide.risso at berkeley.edu <mailto:davide.risso at berkeley.edu>>>

      ------------------------------------------------------------------------
      <http://www.avast.com/ <http://www.avast.com/> <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/> <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.risso at berkeley.edu <mailto:davide.risso at berkeley.edu> <mailto:davide.risso at berkeley.edu <mailto:davide.risso at berkeley.edu>> <mailto:davide.risso at berkeley.edu <mailto:davide.risso at berkeley.edu> <mailto:davide.risso at berkeley.edu <mailto:davide.risso at berkeley.edu>>>

  ------------------------------------------------------------------------
  <http://www.avast.com/ <http://www.avast.com/> <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/> <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]]



------------------------------

       [[alternative HTML version deleted]]

-- 
Steve Lianoglou
Computational Biologist
Genentech

On Oct 31, 2014, at 3:53 PM, "Ryan C. Thompson" <rct at 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
<thomasp85 at 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.michael at 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 <thomasp85 at gmail.com <mailto:thomasp85 at 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.coombes at gmail.com <mailto:kevin.r.coombes at 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.coombes at gmail.com <mailto:kevin.r.coombes at gmail.com> <mailto:kevin.r.coombes at gmail.com <mailto:kevin.r.coombes at 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.coombes at gmail.com <mailto:kevin.r.coombes at gmail.com> <mailto:kevin.r.coombes at gmail.com <mailto:kevin.r.coombes at 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.coombes at gmail.com <mailto:kevin.r.coombes at gmail.com>
       <mailto:kevin.r.coombes at gmail.com <mailto:kevin.r.coombes at 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.coombes at gmail.com <mailto:kevin.r.coombes at gmail.com>
           <mailto:kevin.r.coombes at gmail.com <mailto:kevin.r.coombes at 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"
               <michaelisaiahlove at gmail.com <mailto:michaelisaiahlove at gmail.com>
               <mailto:michaelisaiahlove at gmail.com <mailto:michaelisaiahlove at 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]]

           ------------------------------------------------------------------------
           <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.risso at berkeley.edu <mailto:davide.risso at berkeley.edu>
       <mailto:davide.risso at berkeley.edu <mailto:davide.risso at 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.risso at berkeley.edu <mailto:davide.risso at berkeley.edu> <mailto:davide.risso at berkeley.edu <mailto:davide.risso at 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]]



------------------------------

        [[alternative HTML version deleted]]

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
<thomasp85 at 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.michael at 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 <
thomasp85 at gmail.com <mailto:thomasp85 at 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.coombes at gmail.com <mailto:
kevin.r.coombes at 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.coombes at gmail.com <mailto:kevin.r.coombes at gmail.com>
<mailto:kevin.r.coombes at gmail.com <mailto:kevin.r.coombes at 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.coombes at gmail.com <mailto:kevin.r.coombes at gmail.com>
<mailto:kevin.r.coombes at gmail.com <mailto:kevin.r.coombes at 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.coombes at gmail.com <mailto:kevin.r.coombes at gmail.
com>
        <mailto:kevin.r.coombes at gmail.com <mailto:
kevin.r.coombes at 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.coombes at gmail.com <mailto:
kevin.r.coombes at gmail.com>
            <mailto:kevin.r.coombes at gmail.com <mailto:
kevin.r.coombes at 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"
                <michaelisaiahlove at gmail.com <mailto:
michaelisaiahlove at gmail.com>
                <mailto:michaelisaiahlove at gmail.com <mailto:
michaelisaiahlove at 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]]

            ------------------------------
------------------------------------------
            <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.risso at berkeley.edu <mailto:
davide.risso at berkeley.edu>
        <mailto:davide.risso at berkeley.edu <mailto:
davide.risso at 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.risso at berkeley.edu <mailto:davide.risso at berkeley.
edu> <mailto:davide.risso at berkeley.edu <mailto:
davide.risso at 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]]



------------------------------

         [[alternative HTML version deleted]]