Re: [Rd] strange behavior from cex="*"
On 18.11.2011 10:14, Patrick Burns wrote: 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. See also the graphicsQC package. Uwe On 17/11/2011 00:29, Duncan Murdoch wrote: On 11-11-16 5:26 PM, Ben Bolker wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 11-11-16 05:18 PM, peter dalgaard wrote: >> >> On Nov 16, 2011, at 22:38 , Ben Bolker wrote: >> >>> 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. >> >> 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. > > 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. Yes, that's where the check was missed. I'll fix it. The other parameters appear to have been checked properly. > 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.] So now you can prove me wrong about the other parameters... Duncan Murdoch > >> >>> >>> 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) >>> }) >>> >>> # >>> sessionInfo() >>> 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 >>> >>> __ >>> R-devel@r-project.org mailing list >>> https://stat.ethz.ch/mailman/listinfo/r-devel >> > > -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- > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] strange behavior from cex="*"
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: On 11-11-16 5:26 PM, Ben Bolker wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 11-11-16 05:18 PM, peter dalgaard wrote: >> >> On Nov 16, 2011, at 22:38 , Ben Bolker wrote: >> >>> 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. >> >> 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. > > 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. Yes, that's where the check was missed. I'll fix it. The other parameters appear to have been checked properly. > 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.] So now you can prove me wrong about the other parameters... Duncan Murdoch > >> >>> >>> 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) >>> }) >>> >>> # >>> sessionInfo() >>> 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 >>> >>> __ >>> R-devel@r-project.org mailing list >>> https://stat.ethz.ch/mailman/listinfo/r-devel >> > > -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- > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel -- Patrick Burns pbu...@pburns.seanet.com twitter: @portfolioprobe http://www.portfolioprobe.com/blog http://www.burns-stat.com (home of 'Some hints for the R beginner' and 'The R Inferno') __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] strange behavior from cex="*"
On 11-11-16 7:29 PM, Duncan Murdoch wrote: On 11-11-16 5:26 PM, Ben Bolker wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11-11-16 05:18 PM, peter dalgaard wrote: On Nov 16, 2011, at 22:38 , Ben Bolker wrote: 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. 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. 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. Yes, that's where the check was missed. I'll fix it. The other parameters appear to have been checked properly. Now fixed in R-devel and R-patched. Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] strange behavior from cex="*"
On 11-11-16 5:26 PM, Ben Bolker wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11-11-16 05:18 PM, peter dalgaard wrote: On Nov 16, 2011, at 22:38 , Ben Bolker wrote: 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. 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. 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. Yes, that's where the check was missed. I'll fix it. The other parameters appear to have been checked properly. 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.] So now you can prove me wrong about the other parameters... Duncan Murdoch 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) }) # sessionInfo() 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-14png_0.1-3 loaded via a namespace (and not attached): [1] grid_2.15.0 lattice_0.19-33 nlme_3.1-102tools_2.15.0 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel -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- __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] strange behavior from cex="*"
On Wed, Nov 16, 2011 at 11:26 PM, Ben Bolker wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > 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 ...) 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... :-) -- Joris Meys Statistical consultant Ghent University Faculty of Bioscience Engineering Department of Mathematical Modelling, Statistics and Bio-Informatics tel : +32 9 264 59 87 joris.m...@ugent.be --- Disclaimer : http://helpdesk.ugent.be/e-maildisclaimer.php __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] strange behavior from cex="*"
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11-11-16 05:18 PM, peter dalgaard wrote: > > On Nov 16, 2011, at 22:38 , Ben Bolker wrote: > >> 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. > > 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. 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.] > >> >> 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) >> }) >> >> # >> >>> sessionInfo() >> 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-14png_0.1-3 >> >> loaded via a namespace (and not attached): >> [1] grid_2.15.0 lattice_0.19-33 nlme_3.1-102tools_2.15.0 >> >> __ >> R-devel@r-project.org mailing list >> https://stat.ethz.ch/mailman/listinfo/r-devel > -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- __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] strange behavior from cex="*"
On Nov 16, 2011, at 22:38 , Ben Bolker wrote: > 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. 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. > > 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) > }) > > # > >> sessionInfo() > 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-14png_0.1-3 > > loaded via a namespace (and not attached): > [1] grid_2.15.0 lattice_0.19-33 nlme_3.1-102tools_2.15.0 > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel -- Peter Dalgaard, Professor, Center for Statistics, Copenhagen Business School Solbjerg Plads 3, 2000 Frederiksberg, Denmark Phone: (+45)38153501 Email: pd@cbs.dk Priv: pda...@gmail.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] strange behavior from cex="*"
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: 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) }) # sessionInfo() 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-14png_0.1-3 loaded via a namespace (and not attached): [1] grid_2.15.0 lattice_0.19-33 nlme_3.1-102tools_2.15.0 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel