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

[Greg Snow]

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?




-- 
Gregory (Greg) L. Snow Ph.D.
538280 at gmail.com