[Rd] unexpected result from reshape
Hi all.
I have unexpected reshape results on datasets with certain variable
names. Here a reproducible example:
d <- matrix(seq_len(7*7), 1, 7*7)
vnames <- c('acc','ppeGross','CF','ROA','DeltaSales','invTA','DeltaRevDeltaRec')
varying <- unlist(lapply(vnames, paste, 1:7, sep='.'))
d <- data.frame(d)
names(d) <- varying
d1 <- reshape(d, varying=varying, direction="long")
d[,'ppeGross.2'] == d1[d1$time==2,'ppeGross'] #This is FALSE!
##Try to compare d and d1: values are wrong from the 2nd column
##Changing variable names makes thinks go right:
vnames <- letters[1:7]
varying <- unlist(lapply(vnames, paste, 1:7, sep='.'))
names(d) <- varying
d1 <- reshape(d, varying=varying, direction="long")
d[,'b.2'] == d1[d1$time==2,'b'] #This is TRUE, as expected
##Try to compare d and d1 now: they look right
Any hint on what's wrong here? By now, my workarond is changing
variable names before reshaping, than re-assign old variable names
back after reshape.
Best regards,
Antonio, Fabio Di Narzo.
> R.version
_
platform i686-pc-linux-gnu
arch i686
os linux-gnu
system i686, linux-gnu
status
major 2
minor 6.0
year 2007
month 10
day03
svn rev43063
language R
version.string R version 2.6.0 (2007-10-03)
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] unexpected result from reshape
I got the problem: dataframe columns are re-ordered alfabetically, but
variable names aren't reordered accordingly in the resulting
dataframe. The problem disappears by specifying the 'varying' argument
as a named list:
d <- matrix(seq_len(7*7), 1, 7*7)
vnames <- c('acc','ppeGross','CF','ROA','DeltaSales','invTA','DeltaRevDeltaRec')
vnames.all <- unlist(lapply(vnames, paste, 1:7, sep='.'))
varying <- split(vnames.all, rep(vnames, each=7))
d <- data.frame(d)
names(d) <- vnames.all
d1 <- reshape(d, varying=varying, direction="long")
d
d1
#Now is ok
2007/11/24, Antonio, Fabio Di Narzo <[EMAIL PROTECTED]>:
> Hi all.
> I have unexpected reshape results on datasets with certain variable
> names. Here a reproducible example:
>
> d <- matrix(seq_len(7*7), 1, 7*7)
> vnames <-
> c('acc','ppeGross','CF','ROA','DeltaSales','invTA','DeltaRevDeltaRec')
> varying <- unlist(lapply(vnames, paste, 1:7, sep='.'))
> d <- data.frame(d)
> names(d) <- varying
> d1 <- reshape(d, varying=varying, direction="long")
> d[,'ppeGross.2'] == d1[d1$time==2,'ppeGross'] #This is FALSE!
> ##Try to compare d and d1: values are wrong from the 2nd column
>
> ##Changing variable names makes thinks go right:
> vnames <- letters[1:7]
> varying <- unlist(lapply(vnames, paste, 1:7, sep='.'))
> names(d) <- varying
> d1 <- reshape(d, varying=varying, direction="long")
> d[,'b.2'] == d1[d1$time==2,'b'] #This is TRUE, as expected
> ##Try to compare d and d1 now: they look right
>
> Any hint on what's wrong here? By now, my workarond is changing
> variable names before reshaping, than re-assign old variable names
> back after reshape.
>
> Best regards,
> Antonio, Fabio Di Narzo.
>
> > R.version
>_
> platform i686-pc-linux-gnu
> arch i686
> os linux-gnu
> system i686, linux-gnu
> status
> major 2
> minor 6.0
> year 2007
> month 10
> day03
> svn rev43063
> language R
> version.string R version 2.6.0 (2007-10-03)
>
--
Antonio, Fabio Di Narzo
Ph.D. student at
Department of Statistical Sciences
University of Bologna, Italy
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] patch proposal for plot.ts
Hi all. Currently, if you try: > lag.plot(1:10) you get superposed labels '1' and '10'. Things go worse in more extreme cases: x <- ts(1:10) x1 <- lag(x, 4) plot(x1, x) This is due to a mistake in plot.ts. My suggestion is the following really minimal patch to plot.ts: @@ -530,7 +530,7 @@ plot.ts <- text(xy, labels = if(is.character(xy.labels)) xy.labels else if(all(tsp(x) == tsp(y))) formatC(time(x), width = 1) -else seq_along(x), +else seq_along(xy$x), col = col, cex = cex) if(xy.lines) lines(xy, col = col, lty = lty, lwd = lwd, Best regards, Antonio. -- Antonio, Fabio Di Narzo Ph.D. student at Department of Statistical Sciences University of Bologna, Italy diff --git a/src/library/stats/R/ts.R b/src/library/stats/R/ts.R index 53de297..de5995c 100644 --- a/src/library/stats/R/ts.R +++ b/src/library/stats/R/ts.R @@ -530,7 +530,7 @@ plot.ts <- text(xy, labels = if(is.character(xy.labels)) xy.labels else if(all(tsp(x) == tsp(y))) formatC(time(x), width = 1) - else seq_along(x), + else seq_along(xy$x), col = col, cex = cex) if(xy.lines) lines(xy, col = col, lty = lty, lwd = lwd, __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] patch proposal for plot.ts
> Antonio, Fabio Di Narzo <[EMAIL PROTECTED]> > on Sat, 24 Nov 2007 12:35:25 +0100 writes: > Hi all. Currently, if you try: >> lag.plot(1:10) > you get superposed labels '1' and '10'. Things go worse in > more extreme cases: > x <- ts(1:10) > x1 <- lag(x, 4) > plot(x1, x) > This is due to a mistake in plot.ts. I agree, It seems pretty clear to you have uncovered a - somewaht rarely tirggered bug there... > My suggestion is the following > really minimal patch to plot.ts: @@ -530,7 +530,7 @@ plot.ts <- text(xy, labels = if(is.character(xy.labels)) xy.labels else if(all(tsp(x) == tsp(y))) formatC(time(x), width = 1) -else seq_along(x), +else seq_along(xy$x), col = col, cex = cex) if(xy.lines) lines(xy, col = col, lty = lty, lwd = lwd, > Best regards, > Antonio. Thank you very much, Antonio, for the nice compact report and patch! This will be fixed in R 2.7.0 and maybe even in 2.6.1 Martin Maechler, ETH Zurich __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Bug in package stats function ar() (PR#10459)
Steven McKinney wrote: > > Full_Name: Steven McKinney > Version: 2.6.0 > OS: OS X > Submission from: (NULL) (142.103.207.10) > > > > Function ar() in package "stats" is showing > a quirky bug. Some calls to ar() run to > completion, others throw an error. > > The bug is reproducible by several people on different > machines, however, the ar() function itself ends > up throwing the error sporadically. Several calls to > ar() may be necessary to trip the error condition. > > Code to reproduce: > > x<-ts(c(-0.2052083,-0.3764986,-0.3762448,0.3740089,0.2737568,2.8235722,-1.7783313,0.2728676,-0.3273164),start=c(1978,3),frequency=4,end=c(1980,3)) > # ar function > res.ar<-ar(x,aic=TRUE,demean=F) > # call "ar" again and > res.ar<-ar(x,aic=TRUE,demean=F) > > > Example output: > (Note that on this attempt the first call to ar() > tripped the error.) > >> x<-ts(c(-0.2052083,-0.3764986,-0.3762448,0.3740089,0.2737568,2.8235722,- > + > 1.7783313,0.2728676,-0.3273164),start=c(1978,3),frequency=4,end=c(1980,3)) >> > Slightly more detail: in the "eureka" function, in stats/src/eureka.f, the last element of "vars" in the return list is bogus and varies among calls; if it comes out to NaN or NA it triggers the bug. Haven't spent any more time yet tracking this down, but hope that will save someone a few minutes. Ben Bolker -- View this message in context: http://www.nabble.com/Bug-in-package-stats-function-ar%28%29-%28PR-10459%29-tf4864536.html#a13926484 Sent from the R devel mailing list archive at Nabble.com. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] unexpected result from reshape
Antonio, Fabio Di Narzo wrote:
> Hi all.
> I have unexpected reshape results on datasets with certain variable
> names. Here a reproducible example:
>
> d <- matrix(seq_len(7*7), 1, 7*7)
> vnames <-
> c('acc','ppeGross','CF','ROA','DeltaSales','invTA','DeltaRevDeltaRec')
> varying <- unlist(lapply(vnames, paste, 1:7, sep='.'))
> d <- data.frame(d)
> names(d) <- varying
> d1 <- reshape(d, varying=varying, direction="long")
> d[,'ppeGross.2'] == d1[d1$time==2,'ppeGross'] #This is FALSE!
> ##Try to compare d and d1: values are wrong from the 2nd column
>
> ##Changing variable names makes thinks go right:
> vnames <- letters[1:7]
> varying <- unlist(lapply(vnames, paste, 1:7, sep='.'))
> names(d) <- varying
> d1 <- reshape(d, varying=varying, direction="long")
> d[,'b.2'] == d1[d1$time==2,'b'] #This is TRUE, as expected
> ##Try to compare d and d1 now: they look right
>
> Any hint on what's wrong here? By now, my workarond is changing
> variable names before reshaping, than re-assign old variable names
> back after reshape.
>
> Best regards,
> Antonio, Fabio Di Narzo.
>
Ouch. This was dumb (*): The problem is the guess() function using
split(nms, nn[,1]), which implicitly runs factor(nn[,1]) and so gives
out the groups in the order of sort(unique(nn[,1])), but later on we
just use unique(nn[,1]).
Fortunately, this is wrong enough and trivial enough to fix, that it can
make it into 2.6.1.
-pd
(*) I think I wrote it, so I can say so.
>
>> R.version
>>
>_
> platform i686-pc-linux-gnu
> arch i686
> os linux-gnu
> system i686, linux-gnu
> status
> major 2
> minor 6.0
> year 2007
> month 10
> day03
> svn rev43063
> language R
> version.string R version 2.6.0 (2007-10-03)
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
--
O__ Peter Dalgaard Øster Farimagsgade 5, Entr.B
c/ /'_ --- Dept. of Biostatistics PO Box 2099, 1014 Cph. K
(*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918
~~ - ([EMAIL PROTECTED]) FAX: (+45) 35327907
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Bug in package stats function ar() (PR#10459)
On 24/11/2007 11:45 AM, Ben Bolker wrote: > > > Steven McKinney wrote: >> Full_Name: Steven McKinney >> Version: 2.6.0 >> OS: OS X >> Submission from: (NULL) (142.103.207.10) >> >> >> >> Function ar() in package "stats" is showing >> a quirky bug. Some calls to ar() run to >> completion, others throw an error. >> >> The bug is reproducible by several people on different >> machines, however, the ar() function itself ends >> up throwing the error sporadically. Several calls to >> ar() may be necessary to trip the error condition. >> >> Code to reproduce: >> >> x<-ts(c(-0.2052083,-0.3764986,-0.3762448,0.3740089,0.2737568,2.8235722,-1.7783313,0.2728676,-0.3273164),start=c(1978,3),frequency=4,end=c(1980,3)) >> # ar function >> res.ar<-ar(x,aic=TRUE,demean=F) >> # call "ar" again and >> res.ar<-ar(x,aic=TRUE,demean=F) >> >> >> Example output: >> (Note that on this attempt the first call to ar() >> tripped the error.) >> >>> x<-ts(c(-0.2052083,-0.3764986,-0.3762448,0.3740089,0.2737568,2.8235722,- >> + >> 1.7783313,0.2728676,-0.3273164),start=c(1978,3),frequency=4,end=c(1980,3)) > > Slightly more detail: in the "eureka" function, in stats/src/eureka.f, the > last > element of "vars" in the return list is bogus and varies among calls; if it > comes out to NaN or NA it triggers the bug. > > Haven't spent any more time yet tracking this down, but hope that > will save someone a few minutes. Thanks, I'll take a look. Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Bug in package stats function ar() (PR#10459)
> "DM" == Duncan Murdoch <[EMAIL PROTECTED]> > on Sat, 24 Nov 2007 16:08:31 -0500 writes: DM> On 24/11/2007 11:45 AM, Ben Bolker wrote: >> >> >> Steven McKinney wrote: >>> Full_Name: Steven McKinney Version: 2.6.0 OS: OS X >>> Submission from: (NULL) (142.103.207.10) >>> >>> >>> >>> Function ar() in package "stats" is showing a quirky >>> bug. Some calls to ar() run to completion, others throw >>> an error. >>> >>> The bug is reproducible by several people on different >>> machines, however, the ar() function itself ends up >>> throwing the error sporadically. Several calls to ar() >>> may be necessary to trip the error condition. >>> >>> Code to reproduce: >>> >>> x<-ts(c(-0.2052083,-0.3764986,-0.3762448,0.3740089,0.2737568,2.8235722,-1.7783313,0.2728676,-0.3273164),start=c(1978,3),frequency=4,end=c(1980,3)) >>> # ar function res.ar<-ar(x,aic=TRUE,demean=F) # call >>> "ar" again and >>> res.ar<-ar(x,aic=TRUE,demean=F) >>> >>> >>> Example output: (Note that on this attempt the first >>> call to ar() tripped the error.) >>> x<-ts(c(-0.2052083,-0.3764986,-0.3762448,0.3740089,0.2737568,2.8235722,- >>> + >>> 1.7783313,0.2728676,-0.3273164),start=c(1978,3),frequency=4,end=c(1980,3)) >> >> Slightly more detail: in the "eureka" function, in >> stats/src/eureka.f, the last element of "vars" in the >> return list is bogus and varies among calls; if it comes >> out to NaN or NA it triggers the bug. >> >> Haven't spent any more time yet tracking this down, but >> hope that will save someone a few minutes. DM> Thanks, I'll take a look. I did too. It seems pretty obvious that we have to require order.max < n.used i.e. order.max <= n.used-1 whereas in the current example, order.max == n.used == 9 I have a small fix which solves the problem and seems to pass make check... Martin __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] r-forge http server down?
Trying to go to http://r-forge.r-project.org/ produces: An error occured in the logger. ERROR: could not access status of transaction 0 DETAIL: could not write to file "pg_subtrans/025C" at offset 122880: No space left on device however, update.packages(repos="http://r-forge.r-project.org";) works. Ben Bolker -- View this message in context: http://www.nabble.com/r-forge-http-server-down--tf4869110.html#a13932760 Sent from the R devel mailing list archive at Nabble.com. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
