On Sun, Nov 2, 2014 at 12:19 AM, Wolfgang Huber wrote:
> Just to bring the discussion back to the fact that there is a need to do
> /something/. A function plotPCA is defined in packages EDASeq, DESeq2,
> DESeq, affycoretools, Rcade, facopy, CopyNumber450k, netresponse, MAIT,
> with a real potent
whatever, here's a patch. If BiocGenerics had a GitHub repo I'd just
submit a pull request. Bounce it or don't, it took 5 minutes of a Sunday
morning for a non-core committer, so it must not be that hard to build a
bikeshed after all. /s
FWIW I once remarked to Robert Gentleman that it seemed w
Just to bring the discussion back to the fact that there is a need to do
/something/. A function plotPCA is defined in packages EDASeq, DESeq2, DESeq,
affycoretools, Rcade, facopy, CopyNumber450k, netresponse, MAIT, with a real
potential for needless user confusion. And BiocGenerics already defi
I see the argument for separating plotting and computation.
I don't see the argument for changing plotPCA to plot. base R has things
that work either way; we all know hist(), boxplot() etc etc. And for this
specific case there are (good) arguments for the fact that one could
envision several plo
On Nov 1, 2014 1:29 PM, "Michael Love" wrote:
>
> As far as the proposal of using the plot() function for all plots, I
> think for the biologists who are struggling already to get R going,
> and to figure out what kinds of plots are possible, plotMA (and
> knowing that the help is available at ?pl
I guess I'm thinking now to move toward breaking up the PCA and plot
in DESeq2, given that there is non-trivial computation going on, and
then to leave plotPCA as a wrapper and to avoid breaking any user
code. We had already moved this way a bit, in that in the current
release, plotPCA has an argum
Sure, the ggplot model (returning an abstract representation of a plot, and
then rendering it when requested, i.e., printed) is preferable to the side
effects of base graphics. Unfortunately, plot() implies the side effect,
which motivated the introduction of autoplot() in ggbio, and in fact we
use
A drag, since hist(foo, plot=FALSE) acts as expected. I emulate this behavior
for most of my code nowadays, not least since I often want to return something
useful, whether plotted or not.
--t
> On Oct 31, 2014, at 3:53 PM, "Ryan C. Thompson" wrote:
>
> I'd just like to chime in that regardl
I could personally live with that though it requires more verbose typing for
the user. But I do miss a sensible explanation for why everything that ends up
on a graphic device should go through one plot generic�
To get back to the plotPCA example that started it all. At least some of us
agree t
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 jus
Hi,
On Fri, Oct 31, 2014 at 2:35 PM, Thomas Lin Pedersen
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 w
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
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
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 ca
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 o
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
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 implement
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 ch
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 -
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
I agree it depends on programming style. But to continue with the example,
it would have to be:
plot(as.mySpecialObjectPCA(mySpecialObject))
because we have many packages here with their own functions.
Wouldn't this just proliferate the number of classes instead of functions?
For every type of p
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 sensibl
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
wrote:
> But shouldn't they all really just be named "plot" for the appropriate
> objects? In which cas
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"
wrote:
> I noticed that 'plotPCA' functions are defined in EDASeq, DESeq2, DESeq,
> affycoretools, Rcade, fa
24 matches
Mail list logo
