[Rd] [FORGED] Different results based on the order of arguments to par

[Paul Murrell]

Hi

I'm going to try to blame user error here.

par(usr) is used to reset the coordinates on the CURRENT plot.

par(plt) is used to specify the location of the NEXT plot.

The correct approach should be to set up the location for the next plot, 
start a new plot, set up coordinates on the new plot.

Neither of your examples performs the "start a new plot" step.

I would expect to see something like ...

dev.new()
hist(rexp(100))
# Set up location of new plot
par(plt=c(0.5,0.9,0.5,0.77))
# Avoid new page
par(new=TRUE)
# Start new plot
plot.new()
# Set up coordinates on new plot
# (though plot.window() might be better here)
par(usr=c(0,1,0,1))
# Start drawing
box()
points(c(0,1), c(0,1), pch=16, col='red', cex=3)

Is there a good argument against doing that?

Paul

On 15/03/16 10:27, Greg Snow wrote:
> I ran into this issue when trying to modify a subplot (subplot
> function in the TeachingDemos package), but here is a more minimal
> example of the issue (I don't know that it is serious enough to call a
> bug):
>
> This code works how I expect:
>
> dev.new()
> hist(rexp(100))
>
> par(plt=c(0.5,0.9,0.5,0.77), usr=c(0,1,0,1))
>
> box() # show new plt region
> points(c(0,1), c(0,1), pch=16, col='red', cex=3)
>
> it creates a histogram then changes the plotting region so that I can
> add an annotation, changes the user coordinates within the new region,
> then plots some points using the new coordinate system.
>
> But if I change the order of the arguments to par like so:
>
> dev.new()
> hist(rexp(100))
>
> par(usr=c(0,1,0,1), plt=c(0.5,0.9,0.5,0.77))
>
> box() #show new plt region
> points(c(0,1), c(0,1), pch=16, col='red')
>
> then the points do not show up (or if we add xpd=NA to the par call
> then we see them outside of the plotting region).  So clearly the
> behavior of par depends on the order of the arguments specified.
>
> This is not explicitly documented, though there is a hinting at the
> behavior in the note on the par help page (it was following this
> warning that led to me first encountering the issue, since I was
> specifying only the parameters that I needed, not everything, and
> happened to specify usr before plt), but "usr" is not included in the
> list in the note (because it does something different from what the
> note is specifically warning about).
>
>
> I see a few different potential responses to this issue:
>
> 1. consider that this is a rare enough issue that only Greg Snow will
> ever care and he has already learned the lesson, so do nothing (other
> than laugh at Greg when he forgets and has to remember to properly
> order his par arguments).
>
> 2. Since this came up as an issue with subplot, force the author of
> subplot and the TeachingDemos package to add a note or warning to the
> documentation for that function.
>
> 3.  Expand the note on the help page for par (or add another note)
> that warns that the order of the parameters matters and to therefore
> be careful in which order you specify arguments (probably with some
> detail on the suggested ordering).  While there will be many users who
> never read this, we will at least be able to point to the note if
> anyone else is affected by this issue.
>
> 4. Modify the par function to reorder the list created from its args
> so that they are evaluated in a consistent order (and probably add
> documentation to the help page to this effect).
>
>
> Thoughts?
>
>
>
>

-- 
Dr Paul Murrell
Department of Statistics
The University of Auckland
Private Bag 92019
Auckland
New Zealand
64 9 3737599 x85392
paul at stat.auckland.ac.nz
http://www.stat.auckland.ac.nz/~paul/