[R] Are there better ways to save and restore par() settings
murdoch.duncan at gmail.com
Sat May 15 01:46:58 CEST 2010
On 14/05/2010 6:19 PM, David Winsemius wrote:
> On May 14, 2010, at 5:45 PM, Duncan Murdoch wrote:
>> On 14/05/2010 3:51 PM, David Winsemius wrote:
>>> Some of the help page examples use the form:
>>> opar <- par(<something>)
>>> .....plotting activities...
>>> This seems to "work" well, yet I have read in some places
>> Please include commented, retrievalbe citations for "some places".
> In the examples from help(par) I see:
> op <- par(mfrow = c(2, 2),
> # 2 x 2 pictures on one plot pty = "s")
> # square plotting region,
> # independent of device size
> ## At end of plotting, reset to previous settings:
> # Alternatively, op <- par(no.readonly = TRUE)
> # the whole list of settable par's.
> ## do lots of plotting and par(.) calls, then reset: par(op)
> ## Note this is not in general good practice
> Was it only with the use of the "no.read.only" parameter that one is
> supposed to avoid the form I illustrated. I had assumed it applied to
> both alternatives.
No, it applies to everything. The general rule of "etiquette" is that
if you change the par() settings, you should restore them when you're done.
>>> that it is not the preferred method to keep you parameters from
>>> getting corrupted. What is the preferred method?
>> The above, with the restore wrapped in on.exit(), as your sources
>> should have said.
> Perhaps it was implied in a manner to which I was not properly
> receptive. The only place I see on.exit() on the par help page is in
> the final example. I do not see a link to that function in the that
> help page, and I had read it but assumed it was related to "exit"-ing
> an R session. On visiting the on.exit help page for the first time in
> my life, I see that its primary use is with graphics device calls. So
> we are being advised to write that wrapper function each time we might
> be making a par-changing plot?
Code contained in "on.exit" expressions is executed when the current
function exits. I would guess the first example didn't use this,
because there's a fiction when running examples that they are run by the
user at the command line: so on.exit() would never execute. (I don't
know what happens if you put a naked on.exit() in example code; I would
guess it would cause trouble, because it would interfere with the way R
already handles the exit from running an example.) You need to read the
comment, which says "At end of plotting, reset to previous settings:".
The on.exit() wrapper is a way of ensuring that this happens when the
code is in a function. No matter how the function exits (even if it
exits due to an error), R will attempt to run that code and restore the
So it is safe to run the example code in almost any context, because it
sets a par() value, then restores it. But real code usually has
something in between those two steps, and it may quit, or return from a
function, or die due to an error. The advice is to write things in a
way that ensures that no matter what goes wrong, if you've changed the
parameters, then you will change them back.
Does that make sense?
More information about the R-help