Skip to content

unexpected par('pin') behaviour

5 messages · Joerg van den Hoff, Martin Maechler

Original
Joerg van den Hoff
# 
hi everybody,

I noticed the following: in one of my scripts 'layout' is used to 
generate a (approx. square) grid of variable dimensions (depending on 
no. of input files). if the no. of subplots (grid cells) becomes 
moderately large  (say > 9) I use a construct like

   ###layout grid computation and set up occurs here###
    ...
   opar <- par(no.readonly = T);
   on.exit(par(opar))
   par(mar=c(4.1, 4.1, 1.1, .1))
   ###plotting occurs here####
    ...

to reduce the figure margins to achieve a more compact display. apart 
from 'mar' no other par() setting is modified.

this works fine until the total number of subplots becomes too large 
("large" depending on the current size of the X11() graphics device 
window, e.g. 7 x 6 subplots for the default size fo x11()).

I then get the error message (only _after_ all plots are correctly 
displayed, i.e. obviously during execution of the above on.exit() call)

Error in par(opar) :
invalid value specified for graphics parameter "pin"


and par("pin") yields:

[1]  0.34864 -0.21419


which indeed is invalid (negative 2nd component).

I'm aware of this note from ?par:

    The effect of restoring all the (settable) graphics parameters as
      in the examples is hard to predict if the device has been resized.
      Several of them are attempting to set the same things in different
      ways, and those last in the alphabet will win.  In particular, the
      settings of 'mai', 'mar', 'pin', 'plt' and 'pty' interact, as do
      the outer margin settings, the figure layout and figure region
      size.


but my problem occurs without any resizing of the x11() window prior to 
resetting par to par(opar).

any ideas, what is going on?

platform powerpc-apple-darwin7.9.0
arch     powerpc
os       darwin7.9.0
system   powerpc, darwin7.9.0
status   Patched
major    2
minor    1.0
year     2005
month    05
day      12
language R

regards,

joerg
Martin Maechler
# 
joerg> hi everybody,
    joerg> I noticed the following: in one of my scripts 'layout' is used to 
    joerg> generate a (approx. square) grid of variable dimensions (depending on 
    joerg> no. of input files). if the no. of subplots (grid cells) becomes 
    joerg> moderately large  (say > 9) I use a construct like

    joerg>   ###layout grid computation and set up occurs here###
    joerg>   ...
    joerg>   opar <- par(no.readonly = T);
    joerg>   on.exit(par(opar))
    joerg>   par(mar=c(4.1, 4.1, 1.1, .1))
    joerg>   ###plotting occurs here####
    joerg>   ...

    joerg> to reduce the figure margins to achieve a more
    joerg> compact display. apart from 'mar' no other par()
    joerg> setting is modified.

yet another example of using  par('no.readonly') when it's not
needed and inefficient.

Replacing the above by

    ###layout grid computation and set up occurs here###    
    ...
     op <- par(mar=c(4.1, 4.1, 1.1, .1))
     on.exit(par(op))
    ###plotting occurs here####

will be much more efficient and even solve your problem with "pin".

But then, yes, there might be another par() problem hidden in
your code / example, 
but unfortunately you have not specified reproducible code.


    joerg> this works fine until the total number of subplots becomes too large 
    joerg> ("large" depending on the current size of the X11() graphics device 
    joerg> window, e.g. 7 x 6 subplots for the default size fo x11()).

    joerg> I then get the error message (only _after_ all plots are correctly 
    joerg> displayed, i.e. obviously during execution of the above on.exit() call)

    joerg> Error in par(opar) :
    joerg> invalid value specified for graphics parameter "pin"

    joerg> and par("pin") yields:

    joerg> [1]  0.34864 -0.21419

you mean *after* all the plotting ,  not the "pin" values in
'opar', right?

    joerg> which indeed is invalid (negative 2nd component).

    joerg> I'm aware of this note from ?par:

    joerg> The effect of restoring all the (settable) graphics parameters as
    joerg> in the examples is hard to predict if the device has been resized.
    joerg> Several of them are attempting to set the same things in different
    joerg> ways, and those last in the alphabet will win.  In particular, the
    joerg> settings of 'mai', 'mar', 'pin', 'plt' and 'pty' interact, as do
    joerg> the outer margin settings, the figure layout and figure region
    joerg> size.

{{which shows you the known  but not widely known fact that
  traditional par() based graphics are ``flawed by design''
  and that's why there is the package "grid" for better 
  designed graphics
}}

    joerg> but my problem occurs without any resizing of the
    joerg> x11() window prior to resetting par to par(opar).

It still would be interesting to get a reproducible example
here, as the posting guide asks for.

Martin


    joerg> any ideas, what is going on?

    joerg> platform powerpc-apple-darwin7.9.0
    joerg> arch     powerpc
    joerg> os       darwin7.9.0
    joerg> system   powerpc, darwin7.9.0
    joerg> status   Patched
		    ^^^^^^^
I hope that this is not the basic problem 

    joerg> major    2
    joerg> minor    1.0
    joerg> year     2005
    joerg> month    05
    joerg> day      12
    joerg> language R

    joerg> regards,

    joerg> joerg
Joerg van den Hoff
#
Martin Maechler wrote:
might be. but at least it is immune against modifying some more 'par' 
settings in the course of modfications  at some other place in the 
programm. inefficiency: should be at the ppm level of total cpu-usage in 
my case, :-). what's so bad with copying back and forth this moderately 
large vector?
right (solves the problem). I'll adopt this change for the time being. 
thank you.
yes
... which seems to my simple mind a lot more complicated to come to 
terms with than the graphics package. I understand that grid is more 
powerful but the subset of functionality provided by 'graphics' seems 
more difficult to use in 'grid'. wrong or right?
===========cut====================
graphics.off()

f <- function(n=7, m=6) {
    nm <- n*m
    layout(matrix(1:(nm),n,m))
    opar <- par(no.readonly = T)
    on.exit(par(opar))
    par(mar = c(4.1, 4.1, 1.1, 0.1))
    for (i in 1:nm) plot(i, pch=(i-1)%%25+1)
    layout(1)
}
f(5) #good
par('pin')
f()  #bad (at least for x11() default size)
par('pin')
===========cut====================
thanks for bothering.
joerg
no, don't think so. that concerned the MacOS GUI, I believe.
Martin Maechler
# 
Thank you, Joerg,
for the reproducable example
......................
  ......................

    joerg> ===========cut====================
    joerg> graphics.off()

    joerg> f <- function(n=7, m=6) {
    joerg> nm <- n*m
    joerg> layout(matrix(1:(nm),n,m))
    joerg> opar <- par(no.readonly = T)
    joerg> on.exit(par(opar))
    joerg> par(mar = c(4.1, 4.1, 1.1, 0.1))
    joerg> for (i in 1:nm) plot(i, pch=(i-1)%%25+1)
    joerg> layout(1)
    joerg> }
    joerg> f(5) #good
    joerg> par('pin')
    joerg> f()  #bad (at least for x11() default size)
    joerg> par('pin')
    joerg> ===========cut====================

which I can simplify to

  graphics.off()
  layout(matrix(1:42,7,6))
  par("pin")

  ## [1]  0.2918620 -0.2974408  --- when using x11() "default" 

clearly a bug in layout()  {which I'll file}

and it seems to me, one that is not shared by
par(mfrow= / mfcol=) settings.

Martin Maechler, ETH Zurich
Martin Maechler
# 
............

    MM> which I can simplify to

    MM> graphics.off()
    MM> layout(matrix(1:42,7,6))
    MM> par("pin")

    MM> ## [1]  0.2918620 -0.2974408  --- when using x11() "default" 

    MM> clearly a bug in layout()  {which I'll file}

exploring more before filing a bug report,

I've now seen that this  *NO BUG*  of layout() 
but rather of the ``design bug'' of old-style graphics which
bites here.

    MM> and it seems to me, one that is not shared by
    MM> par(mfrow= / mfcol=) settings.

That's wrong, since

  postscript(paper="a4")
  par(mfrow=c(7,6))
  par("pin")
  ## [1]  1.0470855 -0.1047263

and when plot() you get message about margins being too wide.

Only after something like

  par(mar= rep(1,4))

you get both valid "pin" and can plot properly.

That's nothing new and not really astonishing,
...

Martin Maechler, ETH Zurich