Andrew,
Here's is a way how your example could be coded with the current
implementation of plot. You can always start with an empty plot and then
add lines or points (or both) using the corresponding functions.
x - seq(-2, 2, 0.1)
plot(x, x, type=n)
mapply(function(f, i) lines(x, f(x), col=i), functions, 1:3)
The current approach saves specification of a couple of parameters that
would otherwise had to be specified, since lines(...) would be equivalent to
plot(..., type=l, add=TRUE), and I think that this adds to clarity.
-Christos
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Andrew Clausen
Sent: Sunday, March 16, 2008 12:05 AM
To: Duncan Murdoch
Cc: R-devel@r-project.org
Subject: Re: [Rd] [patch] add=TRUE in plot.default()
Hi Duncan,
On Mon, Mar 10, 2008 at 08:51:23AM -0400, Duncan Murdoch wrote:
The add parameter only interacts with other parameters
superficially
-- some parameters of plot (like log) are related to the
shape of
the axes, and should be inherited from what is on the plot already.
I'd say causing some parameters to be completely ignored without a
warning is more than a superficial interaction.
Fair enough. I suppose you could inadvertantly put leave
add=TRUE in some code, and wonder why axes aren't getting drawn.
Really, add=TRUE is not
a great design: it would be better to say plot methods draw a new
plot (so they need args for all the decorations like axes, titles,
etc.), and have other ways to add things to plots.
I don't like the idea of having a separate way to add to plots.
I like the look of this code:
f - function(x) x^2
g - function(x) 1/x - 1
h - function(x) x
functions - c(f, g, h)
for (i in 1:length(functions))
plot(functions[[i]], add=i1, col=i)
Of course, I'd prefer something like
plot.new()
for (i in 1:length(functions))
plot(functions[[i]], add=TRUE, col=i)
but that seems out of reach for compatibility reasons.
How would you write this code in R today?
Hadley was right on
this, his ggplot2 has a better thought-out design than
classic graphics.
However, we have what we have.
I'm sure ggplot2 is vastly better, although I couldn't find a
quick intro.
(Typing ggplot2 examples into Google didn't help me.)
Since plot() isn't deprecated yet, it's worth making cheap
useful improvements.
I agree. Adding an add=FALSE parameter to plot() would generate
errors for methods that don't implement it, so they would
all have to
be changed simultaneously, including in private/unreleased code.
So I'd like to settle for second best: adding add=FALSE
parameters to
many plot methods.
I like that suggestion better than adding it here and
there, one at a
time. So, to advance the discussion: can you take a look
at the plot
methods that are in the base and recommended packages, and work out
how many already have it, how many would be improved if it
was added,
and in how many cases it just wouldn't make sense? (You
could also do
this on all the CRAN and Bioconductor packages, but that would be
about 100 times more work: about 50 times as many packages,
and much
less consistency in the programming and documentation standards.
Maybe on a subset of popular ones, e.g. those that Rcmdr suggests?)
I had a quick look at the base packages. (I did a crude
search with find and grep on the R source tarball.) I
attached the full list. There were 40 files
containing plot methods. Of these, 9 already implemented
add=TRUE explicitly
and a further 9 inherited it from other plot methods that
could or already do implement it. There were 2 methods for
which it clearly makes no sense. For example, plot.lm makes
no sense because it does several separate plots, one after the other.
It looks reasonably straightforward to implement most of the
remaining methods.
I must confess I don't understand what all of these plots are
doing from a statistics point of view, but I suppose this
shouldn't matter. (Econometrics uses different language...)
Data like that could make a convincing argument that the effort of
adding this to the base packages is worthwhile. (To get it
added to
non-base packages will require you to convince their
maintainers that
it's a good idea.) Another helpful part of the argument
will be for
you to volunteer to do the work of both code and
documentation updates.
I'm not very excited about doing work outside of base. I can
do the base code + documentation though. Any volunteers?
Cheers,
Andrew
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
