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
