Skip to content

strange behavior from cex="*"

9 messages · Ben Bolker, Kevin Coombes, Peter Dalgaard +4 more

#
Someone inquired on StackOverflow about apparently non-deterministic
graphics behaviour in R.  I noticed that they were using cex="*" and
discovered some potentially weird behavior.

   On repeated runs of the same code I can get different PNGs.  If I set
the number of runs high enough, I seem to be able to get R to hang.
If I do a single version plotting to an interactive graphics window I
can get the point sizes to jump around as I resize the window (someone
reported being able to reproduce that behaviour in the Windows GUI as well).

  This is clearly a user error, but non-deterministic behaviour (and
hanging) are a little disturbing.

  I haven't had a chance yet to try to dig in and see what's happening
but thought I would report to see if anyone else could reproduce/figure
it out.

  Ben Bolker


########################
## n <- 100  ## hangs R

n <- 33

fn <- paste("tmp",seq(n),"png",sep=".")
for (i in seq(n)) {
    png(fn[i])
    plot(1:10,1:10,cex="*");
    dev.off()
}

ff <- subset(file.info(fn),select=size)
ff <- ff[!duplicated(ff$size),,drop=FALSE]
table(ff$size)
require(png)
pngs <- lapply(rownames(ff),readPNG)

png.to.img <- function(x) matrix(rgb(x[,,1],x[,,2],x[,,3]),
                                 nrow=dim(x)[1],ncol=dim(x)[2])

imgs <- lapply(pngs,png.to.img)

par(mfrow=c(2,2))
lapply(imgs,function(x) {
  plot(0:1,0:1,type="n",ann=FALSE,axes=FALSE)
  rasterImage(x,0,0,1,1)
})

#########################
R Under development (unstable) (2011-10-06 r57181)
Platform: i686-pc-linux-gnu (32-bit)

attached base packages:
[1] stats     graphics  grDevices utils     datasets  methods   base

other attached packages:
[1] glmmADMB_0.6.5 MASS_7.3-14    png_0.1-3

loaded via a namespace (and not attached):
[1] grid_2.15.0     lattice_0.19-33 nlme_3.1-102    tools_2.15.0
#
Hi Ben,

Just a few things to add.

First, the same phenomenon occurs when you use any character string as 
the value of cex; there is nothing special about "*".

Second, you cannot get this phenomenon by trying to do something like
     par(cex="*")
because the par function actually checks if the value is a nonnegative 
number.

Finally, producing the different graphs is clearly occuring inside the 
"plot.xy" function, although I have not yet caused R2.14 to hang. This 
at least suggests a fix: make sure that plot.xy checks the type of the 
cex argument in the same way that par does.

     Kevin

#######################
  xy <- xy.coords(1:10, 1:10)
  plot(xy)
  for(i in seq(100)) plot.xy(xy, "p", cex="*", col=i)
#######################

 > sessionInfo()
R version 2.14.0 (2011-10-31)
Platform: x86_64-pc-mingw32/x64 (64-bit)

locale:
[1] LC_COLLATE=English_United States.1252
[2] LC_CTYPE=English_United States.1252
[3] LC_MONETARY=English_United States.1252
[4] LC_NUMERIC=C
[5] LC_TIME=English_United States.1252

attached base packages:
[1] stats     graphics  grDevices utils     datasets  methods   base

other attached packages:
[1] png_0.1-3

loaded via a namespace (and not attached):
[1] tools_2.14.0
On 11/16/2011 3:38 PM, Ben Bolker wrote:
#
On Nov 16, 2011, at 22:38 , Ben Bolker wrote:

            
It can be reproduced much more simply (well, not the hang, but bad enough):

In a plain R application console (OSX Snow Leopard),

for (i in 1:100) plot(1:10,cex="*")

will _sometimes_ show big circles, indicating random data being picked up. 

The "cex" is by definition numeric, so you can't expect to be able to pass a character string, but the code should check.

  
    
#
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 11-11-16 05:18 PM, peter dalgaard wrote:
Looks (?) like the check could go in FixupCex (which already tests for
isReal, isInteger, and isLogical) in src/main/plot.c , unless there is a
wish to catch it earlier/in R code.

  It's mildly surprising to me that people can continue to find odd
cases like this after more than 10 years (and imagine how many
cumulative hours of R use ...) [I'm assuming that this hole has been
present for a log time: I don't have the patience to do the SVN
archaeology to find out how long.]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJOxDiKAAoJED2whTVMEyK9ThoIAIjyMpzZqsjUpJVbAb9K8IrL
LbSFh8zb+cZb90ABkFwJaZ2FNTKCjPrUzOYzxxHuU9AY0bdPQGbIm2hvQfzcuMlc
urS/ILIMzZEFSYkqkj0mWI9SADyJ+W0YeN/t3EuWy8nZqUkYQZ8M0GsuXjhtUL/i
hVJU0uuIWCOCHpeI3SQKoxviTE6MQFRXXWhCAJx01h8ee/5UQ5GSGB7Er2Zilld3
0sLI6dmoF7gbeYqz33MaEpQ7geJoW3tfnVbQWUlF86+jGGv5trIqWYIp33OYIxMO
u2YUq51vB+4uIRPFJ4Oyr+nJF0Z9NH4IJBipp/bF6wQ5u6JdXFqKTPeQ1V6m5qk=
=YajM
-----END PGP SIGNATURE-----
#
On Wed, Nov 16, 2011 at 11:26 PM, Ben Bolker <bbolker at gmail.com> wrote:
Mildly surprising? It's astonishing once you realize that for more
than 10 years people were actually using the cex argument as intended.
There is hope for mankind after all... :-)
#
On 11-11-16 5:26 PM, Ben Bolker wrote:
Yes, that's where the check was missed.  I'll fix it.  The other 
parameters appear to have been checked properly.
So now you can prove me wrong about the other parameters...

Duncan Murdoch
#
On 11-11-16 7:29 PM, Duncan Murdoch wrote:
Now fixed in R-devel and R-patched.

Duncan Murdoch
#
Someone ambitious could find problems like
this using random input testing like I talked
about at useR last summer.

http://www.burns-stat.com/pages/Present/random_input_test_annotated.pdf

Testing graphics would be more labor intensive
than the testing I do, but you could think of it
as a video game.
On 17/11/2011 00:29, Duncan Murdoch wrote:

  
    
1 day later
#
On 18.11.2011 10:14, Patrick Burns wrote:
See also the graphicsQC package.

Uwe