[R] par("plt") behaving inconsistely? bug?

Thu Oct 9 04:16:29 CEST 2014

Hi

The canonical poison is this ...

par(plt)
plot.new()
...
par(plt)
par(new=TRUE)
plot.new()
...
par(plt)
par(new=TRUE)
plot.new()

The idea is to set up parameters that control the placement of a plot, 
e.g., par(plt), and then start a plot, with plot.new().  If you want 
more than one plot on a page (and par(mfrow) does not suffice) then you 
set up new placement parameters, tell R not to start a new page, with 
par(new=TRUE), then start another plot, with plot.new().

Your code does not follow the "spirit" of the R graphics model because 
it starts a plot with one set of placement parameters and then changes 
those placement parameters several times within the same plot (instead 
of starting a new plot for each new set of placement parameters).

I had a look at the C code that leads to your "surprising" result and 
there is at least one infelicity in there, but I could not see a simple 
fix that would make your example "work" without a high risk of breaking 
other things.  So I'm afraid my best advice is to change your code to 
work with the graphics system.

The layout() function might provide a less unpleasant approach to having 
more than one plot region on the page, depending on how complex your 
arrangement of plot regions is.

Another alternative is to use the 'grid' graphics package, which is 
designed to allow for the flexible creation of multiple regions, 
depending on what you want to draw in each of those regions.

Paul

On 10/07/14 15:33, Murat Tasan wrote:
> 6. iteratively downgrade to earlier versions of R until it's working
> again... then try to diff out the offending source code change.
> i can try this, but i probably won't get to it for at least a few weeks :-/
>
> in the meantime, i'm tacking on box(lty = 0) to every par(plt = ...) call, e.g.
>> par("plt" = some_plt_coordinates); box(lty = 0)
>
> in the short term, this works.
> clip(...), a combination of par("new" = TRUE); plot.new(), and a whole
> bunch of other kludges work, too... pick your poison :-)
>
> cheers and thanks!
>
> -murat
>
> On Mon, Oct 6, 2014 at 2:08 PM, Greg Snow <538280 at gmail.com> wrote:
>> I believe that what is happening is that the clipping region is being
>> reset when you call box, but not when you call rect.  If you insert
>> the command "par(xpd=NA)" (or TRUE instead of NA) after the plot.new
>> and use the rect commands then you can see both rectangles (because
>> this turns the clipping off).  Working with the clipping region
>> (indirectly in your case) is complex since some functions properly
>> reset the region and others do not (and  making the others
>> automatically reset it may cause other problems when they reset a
>> clipping region that should not be reset).
>>
>> So the options are:
>>
>> 1 dive into the source code enough to figure out if fixing rect to
>> work with the clipping region is simple or not and submitting a patch
>> 2 wait for Prof Brian Ripley to notice this fact and do the above (he
>> has fixed a couple of other functions when made aware)
>> 3 use par(xpd=TRUE) (or NA) to not clip to the plotting region (this
>> is simple, but will allow things to be drawn outside of the plotting
>> region, on simple example is using abline)
>> 4 use a function that properly sets the clipping region (such as box)
>> before plotting anything else
>> 5 call clip(0,1,0,1) (or with the actual user coordinates) to manually
>> set the clipping region
>> 6 other?
>>
>>
>> On Mon, Oct 6, 2014 at 12:00 PM, Murat Tasan <mmuurr at gmail.com> wrote:
>>> Hi all -- I just encountered a behavior that I believe has changed
>>> from previous versions, though I haven't chased back the last version
>>> that behaves as my existing code expects quite yet.
>>> Perhaps this is a bug, though perhaps I'm missing a subtle detail
>>> somewhere in the documentation...
>>>
>>> Here's some code that works as expected (in R 3.1.1):
>>>
>>> ########################################
>>> pdf()
>>> plot.new()
>>>
>>> original_plt <- par("plt")
>>>
>>> plt_1 <- c(original_plt[1],
>>>             original_plt[1] + (original_plt[2] - original_plt[1]) / 2,
>>>             original_plt[3],
>>>             original_plt[3] + (original_plt[4] - original_plt[3]) / 2)
>>> par("plt" = plt_1)
>>> plot.window(xlim = c(0, 1), ylim = c(0, 1))
>>> box()
>>> plt_2 <- c(plt_1[2],
>>>             original_plt[2],
>>>             plt_1[4],
>>>             original_plt[4])
>>> par("plt" = plt_2)
>>> plot.window(xlim = c(0, 1), ylim = c(0, 1))
>>> box()
>>> par("plt" = original_plt)
>>> box(lty = 2)
>>> dev.off()
>>> ########################################
>>>
>>> This will draw 3 boxes... one in the lower left corner (specified by
>>> plt_1), one in the top right corner (specified by plt_2), and one
>>> dotted box around the full plot box (original_plt).
>>>
>>> Now, if you replace the first two box() calls by: rect(0, 0, 1, 1),
>>> only the lower-left rectangle is drawn.
>>> If you _add_ rect(0, 0, 1, 1) after each box() call, all boxes and
>>> rectangles are correctly drawn.
>>>
>>> It seems that after setting plt once, subsequent plt alterations put
>>> the device into a state that will permits drawing of _some_ things
>>> (e.g. box()), but not other things (e.g. rect, lines, points).
>>>
>>> A kludge to fix this is to call box(col = "white")... but that's quite
>>> the kludge, indeed!
>>> Axis() works just like box(), too... but I haven't exhausted which
>>> drawing functions work and which don't.
>>>
>>> I'd classify this is a bug, but I thought I'd check here first.
>>> I've also only checked this so far with the pdf() device, so I don't
>>> know if it is somehow device-specific.
>>>
>>> I detected this because some existing code (that worked on some
>>> earlier version of R, sorry that I don't know which one yet...) has
>>> suddenly stopped working!
>>>
>>> Cheers!
>>>
>>> -murat
>>>
>>> ______________________________________________
>>> R-help at r-project.org mailing list
>>> https://stat.ethz.ch/mailman/listinfo/r-help
>>> PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
>>> and provide commented, minimal, self-contained, reproducible code.
>>
>>
>>
>> --
>> Gregory (Greg) L. Snow Ph.D.
>> 538280 at gmail.com
>
> ______________________________________________
> R-help at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-help
> PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
> and provide commented, minimal, self-contained, reproducible code.
>

-- 
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/