Closed Derek-Jones closed 6 years ago
plot.type
is an argument to plot.visreg
, not visreg
. For this to work, you would have to submit
t <- visreg2d(..., plot=FALSE)
plot(t, plot.type="persp")
Thanks for such a prompt response.
This behavior is user unfriendly. Why not just have visreg2d
return the information so plot
can make use of it (also for the axis labels)?
The documentation does not specify that image is used unless explicitly specified (not that I had previously read the documentation)
I see what you're saying, but I don't agree. Part of the value of allowing the user to break the plot up into two steps is to separate the construction of the object from how it's plotted:
fit <- lm(Ozone ~ Solar.R + Wind + Temp, data=airquality)
v <- visreg(fit, 'Wind', plot=FALSE)
plot(v)
plot(v, gg=TRUE)
plot(v, line.par=list(col='red'))
Options that change the appearance of the plot need to be passed to the plotting function...to me, that seems straightforward.
Yes it does, see ?plot.visreg2d
.
Yes, plot
should be able to override previously specified values. But why force users down this path? It also makes the use of plot
inflexible.
Requiring that plot
duplicate the presentation information present in the call to visreg2d
ties that call to plot
down to always plotting the value returned by on call to visreg2d
.
It means that the decision about what to plot
cannot be decided at runtime, or by passing a value to a function.
The documentation requires me to switch my brain on, rather than rely on default assumptions.
There is no inflexibility; users are not required to match or duplicate anything in calls to plot
.
Specifying
visreg2d(..., plot.type="persp", plot=FALSE)
is not meaningful. You're telling visreg
not to plot anything, but also telling it the type of nothing it should plot.
visreg
/visreg2d
isvisreg(fit, 'var', options)
which works fine and does not require users to "switch their brain on" or carefully read the documentation. The package also allows users to break this up into two steps if they are trying to accomplish something advanced that requires additional customization:
v <- visreg(fit, 'var', plot=FALSE)
plot(v)
It seems reasonable to me that if you're trying to accomplish advanced customization, that you would probably want to read the documentation. Can I ask what you're trying to accomplish by splitting the plotting into two separate steps?
I'm working on a book and am using Asciidoc, preprocessing files with the ascii package to generate the pdfs.
For whatever reason, pdfs don't appear unless they are generated using a plot
function. At least they don't for the lattice
functions and a few other packages (I have not tried with visreg
, I just assumed).
My working habit is to tune interactively and then add a call to plot
last. So I got caught out by this behavior, which I have not seen in other packages.
Ah, I see; that makes more sense now. Yes, certain packages like lattice
and ggplot2
don't plot inside certain environments unless there's an explicit request to plot:
library(lattice)
f <- function() {
xyplot(lat ~ long | cut(Depth, 5), data = quakes)
}
y <- f() # Doesn't plot
# All of these plot
y
print(y)
plot(y)
However, this doesn't happen with visreg
:
library(visreg)
fit <- lm(Ozone ~ Solar.R + Wind + Temp, data=airquality)
f <- function() {
visreg(fit, 'Wind', by='Temp')
}
y <- f() # Plots, even though a lattice plot is being produced
ggplot2
plots(gg=TRUE
) are an exception, though -- there, the gg object is returned because it is possible to add things to it or customize it prior to plotting.
if (a)
X=visreg(fit, 'Wind', by='Temp', xlab="Wind info")
else
X=visreg(fit, 'Temp', by='Wind, xlab="Temp info")
# Some code
plot(X, xlab="Wind or Temp info")
results in an image being plotted, i.e., acts as-if
plot.type="image"