(Moved from r-devel to r-bugs) On 3/24/2006 5:03 AM, Antonio, Fabio Di Narzo wrote:> Hi all. > There's a bug in plot.acf, when plotting acf for multivariate time series. > Here a reproducible example: > > X <- rnorm(1000) > Y <- -X + rnorm(1000, sd=0.6) > Z <- cbind(X,Y) > > In > acf(Z) > cross-correlation plot y-axis is limited to 0-1. But: > acf(Z, ylim=c(-1,1)) > shows that there was a negative correlation, that was cut away in the > previous plot. > > I've seen the error is trivial. There's something like: > > for(each pair of univariate time series) { > if(is.null(ylim)) { > ...#set ylim properly > } > ... > } > > in plot.acf code, so that in the first iteration the ylim par is properly > set to about c(0,1), but in > subsequent interations, ylim is no more NULL, and the old, unproper ylim > specification > remains.Thanks for noticing this. It's easy to fix, but before I do, I'd like an opinion on the proper fix. Should all the plots use the same ylim, or in the case where it is unspecified, should they each choose their own? I can see arguments for both possibilities. Duncan Murdoch> > Antonio, Fabio Di Narzo. > > P.S. Sorry for not indicating exact source lines, but from this PC I don't > have access to > R sources... > > [[alternative HTML version deleted]] > > ______________________________________________ > R-devel at r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel
>>>>> "Duncan" == Duncan Murdoch <murdoch at stats.uwo.ca> >>>>> on Fri, 24 Mar 2006 13:55:03 +0100 (CET) writes:Duncan> (Moved from r-devel to r-bugs) Duncan> On 3/24/2006 5:03 AM, Antonio, Fabio Di Narzo wrote: >> Hi all. >> There's a bug in plot.acf, when plotting acf for multivariate time series. >> Here a reproducible example: >> >> X <- rnorm(1000) >> Y <- -X + rnorm(1000, sd=0.6) >> Z <- cbind(X,Y) >> >> In >> acf(Z) >> cross-correlation plot y-axis is limited to 0-1. But: >> acf(Z, ylim=c(-1,1)) >> shows that there was a negative correlation, that was cut away in the >> previous plot. >> >> I've seen the error is trivial. There's something like: >> >> for(each pair of univariate time series) { >> if(is.null(ylim)) { >> ...#set ylim properly >> } >> ... >> } >> >> in plot.acf code, so that in the first iteration the ylim par is properly >> set to about c(0,1), but in >> subsequent interations, ylim is no more NULL, and the old, unproper ylim >> specification >> remains. Duncan> Thanks for noticing this. It's easy to fix, but Duncan> before I do, I'd like an opinion on the proper fix. Duncan> Should all the plots use the same ylim, or in the Duncan> case where it is unspecified, should they each Duncan> choose their own? I can see arguments for both Duncan> possibilities. Duncan> Duncan Murdoch I'd vote for the first one, a common y-scale. Only that is also consistent with the behavior of explicitly speficied 'ylim'. Martin >> >> Antonio, Fabio Di Narzo. >> >> P.S. Sorry for not indicating exact source lines, but from this PC I don't >> have access to >> R sources...
On 3/24/06, murdoch at stats.uwo.ca <murdoch at stats.uwo.ca> wrote:> (Moved from r-devel to r-bugs) > > On 3/24/2006 5:03 AM, Antonio, Fabio Di Narzo wrote: > > Hi all. > > There's a bug in plot.acf, when plotting acf for multivariate time series. > > Here a reproducible example: > > > > X <- rnorm(1000) > > Y <- -X + rnorm(1000, sd=0.6) > > Z <- cbind(X,Y) > > > > In > > acf(Z) > > cross-correlation plot y-axis is limited to 0-1. But: > > acf(Z, ylim=c(-1,1)) > > shows that there was a negative correlation, that was cut away in the > > previous plot. > > > > I've seen the error is trivial. There's something like: > > > > for(each pair of univariate time series) { > > if(is.null(ylim)) { > > ...#set ylim properly > > } > > ... > > } > > > > in plot.acf code, so that in the first iteration the ylim par is properly > > set to about c(0,1), but in > > subsequent interations, ylim is no more NULL, and the old, unproper ylim > > specification > > remains. > > Thanks for noticing this. It's easy to fix, but before I do, I'd like > an opinion on the proper fix. Should all the plots use the same ylim, > or in the case where it is unspecified, should they each choose their > own? I can see arguments for both possibilities. >Not sure if its worth considering this but plot.zoo allows ylim to be a pair or it can be a list of pairs to specify different ylims for each plot or it can be a labelled list to specify just those indicated with the unspecified ones being defaulted. Also if can be a set of data points in which case its range it used. z <- zoo(cbind(a = 1:10, b = 11:20, c = 21:30)) plot(z, ylim = list(c(1,20), c(1,40), c(1,60))) plot(z, ylim = c(1,40)) plot(z, ylim = list(b = c(1,40))) # a and c get default and b gets indicated one plot(z, ylim = list(c(1,40), a = c(1, 10))) # default is c(1,40) and a is c(1,10) plot(z, ylim = list(1:40, a = 1:10)) # same
This is fixed now in R-devel and R-patched. Thanks again for the report. Duncan Murdoch On 3/24/2006 7:55 AM, murdoch at stats.uwo.ca wrote:> (Moved from r-devel to r-bugs) > > On 3/24/2006 5:03 AM, Antonio, Fabio Di Narzo wrote: >> Hi all. >> There's a bug in plot.acf, when plotting acf for multivariate time series. >> Here a reproducible example: >> >> X <- rnorm(1000) >> Y <- -X + rnorm(1000, sd=0.6) >> Z <- cbind(X,Y) >> >> In >> acf(Z) >> cross-correlation plot y-axis is limited to 0-1. But: >> acf(Z, ylim=c(-1,1)) >> shows that there was a negative correlation, that was cut away in the >> previous plot. >> >> I've seen the error is trivial. There's something like: >> >> for(each pair of univariate time series) { >> if(is.null(ylim)) { >> ...#set ylim properly >> } >> ... >> } >> >> in plot.acf code, so that in the first iteration the ylim par is properly >> set to about c(0,1), but in >> subsequent interations, ylim is no more NULL, and the old, unproper ylim >> specification >> remains. > > Thanks for noticing this. It's easy to fix, but before I do, I'd like > an opinion on the proper fix. Should all the plots use the same ylim, > or in the case where it is unspecified, should they each choose their > own? I can see arguments for both possibilities. > > Duncan Murdoch > > >> >> Antonio, Fabio Di Narzo. >> >> P.S. Sorry for not indicating exact source lines, but from this PC I don't >> have access to >> R sources... >> >> [[alternative HTML version deleted]] >> >> ______________________________________________ >> R-devel at r-project.org mailing list >> https://stat.ethz.ch/mailman/listinfo/r-devel > > ______________________________________________ > R-devel at r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel