strange behavior from cex="*"

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

strange behavior from cex="*"

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

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: strange behavior from cex="*"

Kevin Coombes
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-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
>
> ______________________________________________
> [hidden email] mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: strange behavior from cex="*"

Peter Dalgaard-2
In reply to this post by bbolker

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-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
>
> ______________________________________________
> [hidden email] 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: [hidden email]  Priv: [hidden email]

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: strange behavior from cex="*"

bbolker
-----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-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
>>
>> ______________________________________________
>> [hidden email] 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-----

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: strange behavior from cex="*"

Joris FA Meys
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 Bio-Informatics

tel : +32 9 264 59 87
[hidden email]
-------------------------------
Disclaimer : http://helpdesk.ugent.be/e-maildisclaimer.php

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: strange behavior from cex="*"

Duncan Murdoch-2
In reply to this post by bbolker
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
>>>
>>> ______________________________________________
>>> [hidden email] 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-----
>
> ______________________________________________
> [hidden email] mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: strange behavior from cex="*"

Duncan Murdoch-2
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

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: strange behavior from cex="*"

Patrick Burns
In reply to this post by Duncan Murdoch-2
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
> >>>
> >>> ______________________________________________
> >>> [hidden email] 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-----
> >
> > ______________________________________________
> > [hidden email] mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-devel
>
> ______________________________________________
> [hidden email] mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>

--
Patrick Burns
[hidden email]
twitter: @portfolioprobe
http://www.portfolioprobe.com/blog
http://www.burns-stat.com
(home of 'Some hints for the R beginner'
and 'The R Inferno')

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: strange behavior from cex="*"

Uwe Ligges-3


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
>> >>>
>> >>> ______________________________________________
>> >>> [hidden email] 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-----
>> >
>> > ______________________________________________
>> > [hidden email] mailing list
>> > https://stat.ethz.ch/mailman/listinfo/r-devel
>>
>> ______________________________________________
>> [hidden email] mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>
>

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel