

Someone inquired on StackOverflow about apparently nondeterministic
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 nondeterministic 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) (20111006 r57181)
Platform: i686pclinuxgnu (32bit)
attached base packages:
[1] stats graphics grDevices utils datasets methods base
other attached packages:
[1] glmmADMB_0.6.5 MASS_7.314 png_0.13
loaded via a namespace (and not attached):
[1] grid_2.15.0 lattice_0.1933 nlme_3.1102 tools_2.15.0
______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/rdevel


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 (20111031)
Platform: x86_64pcmingw32/x64 (64bit)
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.13
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 nondeterministic
> 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 nondeterministic 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) (20111006 r57181)
> Platform: i686pclinuxgnu (32bit)
>
> attached base packages:
> [1] stats graphics grDevices utils datasets methods base
>
> other attached packages:
> [1] glmmADMB_0.6.5 MASS_7.314 png_0.13
>
> loaded via a namespace (and not attached):
> [1] grid_2.15.0 lattice_0.1933 nlme_3.1102 tools_2.15.0
>
> ______________________________________________
> [hidden email] mailing list
> https://stat.ethz.ch/mailman/listinfo/rdevel______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/rdevel


On Nov 16, 2011, at 22:38 , Ben Bolker wrote:
> Someone inquired on StackOverflow about apparently nondeterministic
> 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 nondeterministic 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) (20111006 r57181)
> Platform: i686pclinuxgnu (32bit)
>
> attached base packages:
> [1] stats graphics grDevices utils datasets methods base
>
> other attached packages:
> [1] glmmADMB_0.6.5 MASS_7.314 png_0.13
>
> loaded via a namespace (and not attached):
> [1] grid_2.15.0 lattice_0.1933 nlme_3.1102 tools_2.15.0
>
> ______________________________________________
> [hidden email] mailing list
> https://stat.ethz.ch/mailman/listinfo/rdevel
Peter Dalgaard, Professor,
Center for Statistics, Copenhagen Business School
Solbjerg Plads 3, 2000 Frederiksberg, Denmark
Phone: (+45)38153501
Email: [hidden email] Priv: [hidden email]
______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/rdevel


BEGIN PGP SIGNED MESSAGE
Hash: SHA1
On 111116 05:18 PM, peter dalgaard wrote:
>
> On Nov 16, 2011, at 22:38 , Ben Bolker wrote:
>
>> Someone inquired on StackOverflow about apparently nondeterministic
>> 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 nondeterministic 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) (20111006 r57181)
>> Platform: i686pclinuxgnu (32bit)
>>
>> attached base packages:
>> [1] stats graphics grDevices utils datasets methods base
>>
>> other attached packages:
>> [1] glmmADMB_0.6.5 MASS_7.314 png_0.13
>>
>> loaded via a namespace (and not attached):
>> [1] grid_2.15.0 lattice_0.1933 nlme_3.1102 tools_2.15.0
>>
>> ______________________________________________
>> [hidden email] mailing list
>> https://stat.ethz.ch/mailman/listinfo/rdevel>
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
______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/rdevel


On Wed, Nov 16, 2011 at 11:26 PM, Ben Bolker < [hidden email]> 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 BioInformatics
tel : +32 9 264 59 87
[hidden email]

Disclaimer : http://helpdesk.ugent.be/emaildisclaimer.php______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/rdevel


On 111116 5:26 PM, Ben Bolker wrote:
> BEGIN PGP SIGNED MESSAGE
> Hash: SHA1
>
> On 111116 05:18 PM, peter dalgaard wrote:
>>
>> On Nov 16, 2011, at 22:38 , Ben Bolker wrote:
>>
>>> Someone inquired on StackOverflow about apparently nondeterministic
>>> 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 nondeterministic 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) (20111006 r57181)
>>> Platform: i686pclinuxgnu (32bit)
>>>
>>> attached base packages:
>>> [1] stats graphics grDevices utils datasets methods base
>>>
>>> other attached packages:
>>> [1] glmmADMB_0.6.5 MASS_7.314 png_0.13
>>>
>>> loaded via a namespace (and not attached):
>>> [1] grid_2.15.0 lattice_0.1933 nlme_3.1102 tools_2.15.0
>>>
>>> ______________________________________________
>>> [hidden email] mailing list
>>> https://stat.ethz.ch/mailman/listinfo/rdevel>>
>
> 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
>
> ______________________________________________
> [hidden email] mailing list
> https://stat.ethz.ch/mailman/listinfo/rdevel______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/rdevel


On 111116 7:29 PM, Duncan Murdoch wrote:
> On 111116 5:26 PM, Ben Bolker wrote:
>> BEGIN PGP SIGNED MESSAGE
>> Hash: SHA1
>>
>> On 111116 05:18 PM, peter dalgaard wrote:
>>>
>>> On Nov 16, 2011, at 22:38 , Ben Bolker wrote:
>>>
>>>> Someone inquired on StackOverflow about apparently nondeterministic
>>>> 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 Rdevel and Rpatched.
Duncan Murdoch
______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/rdevel


Someone ambitious could find problems like
this using random input testing like I talked
about at useR last summer.
http://www.burnsstat.com/pages/Present/random_input_test_annotated.pdfTesting 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 111116 5:26 PM, Ben Bolker wrote:
> > BEGIN PGP SIGNED MESSAGE
> > Hash: SHA1
> >
> > On 111116 05:18 PM, peter dalgaard wrote:
> >>
> >> On Nov 16, 2011, at 22:38 , Ben Bolker wrote:
> >>
> >>> Someone inquired on StackOverflow about apparently nondeterministic
> >>> 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 nondeterministic 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) (20111006 r57181)
> >>> Platform: i686pclinuxgnu (32bit)
> >>>
> >>> attached base packages:
> >>> [1] stats graphics grDevices utils datasets methods base
> >>>
> >>> other attached packages:
> >>> [1] glmmADMB_0.6.5 MASS_7.314 png_0.13
> >>>
> >>> loaded via a namespace (and not attached):
> >>> [1] grid_2.15.0 lattice_0.1933 nlme_3.1102 tools_2.15.0
> >>>
> >>> ______________________________________________
> >>> [hidden email] mailing list
> >>> https://stat.ethz.ch/mailman/listinfo/rdevel> >>
> >
> > 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
> >
> > ______________________________________________
> > [hidden email] mailing list
> > https://stat.ethz.ch/mailman/listinfo/rdevel>
> ______________________________________________
> [hidden email] mailing list
> https://stat.ethz.ch/mailman/listinfo/rdevel>

Patrick Burns
[hidden email]
twitter: @portfolioprobe
http://www.portfolioprobe.com/bloghttp://www.burnsstat.com(home of 'Some hints for the R beginner'
and 'The R Inferno')
______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/rdevel


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.burnsstat.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 111116 5:26 PM, Ben Bolker wrote:
>> > BEGIN PGP SIGNED MESSAGE
>> > Hash: SHA1
>> >
>> > On 111116 05:18 PM, peter dalgaard wrote:
>> >>
>> >> On Nov 16, 2011, at 22:38 , Ben Bolker wrote:
>> >>
>> >>> Someone inquired on StackOverflow about apparently nondeterministic
>> >>> 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 nondeterministic 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) (20111006 r57181)
>> >>> Platform: i686pclinuxgnu (32bit)
>> >>>
>> >>> attached base packages:
>> >>> [1] stats graphics grDevices utils datasets methods base
>> >>>
>> >>> other attached packages:
>> >>> [1] glmmADMB_0.6.5 MASS_7.314 png_0.13
>> >>>
>> >>> loaded via a namespace (and not attached):
>> >>> [1] grid_2.15.0 lattice_0.1933 nlme_3.1102 tools_2.15.0
>> >>>
>> >>> ______________________________________________
>> >>> [hidden email] mailing list
>> >>> https://stat.ethz.ch/mailman/listinfo/rdevel>> >>
>> >
>> > 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
>> >
>> > ______________________________________________
>> > [hidden email] mailing list
>> > https://stat.ethz.ch/mailman/listinfo/rdevel>>
>> ______________________________________________
>> [hidden email] mailing list
>> https://stat.ethz.ch/mailman/listinfo/rdevel>>
>
______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/rdevel

