[Rd] Bug in all.equal() or in the plm package
Hi!
I noticed that there is a (minor) bug either the command all.equal()
or in the "plm" package. I demonstrate this using an example taken
from the documentation of plm():
==
R> data("Produc", package="plm")
R> zz <- plm(log(gsp)~log(pcap)+log(pc)+log(emp)+unemp,
+ data=Produc, index=c("state","year"))
R> all.equal(zz,zz)
[1] TRUE
Warning message:
In if (length(target) != length(current)) return(paste("target,
current differ in having response: ", :
the condition has length > 1 and only the first element will be used
> all.equal(zz$formula,zz$formula)
[1] TRUE
Warning message:
In if (length(target) != length(current)) return(paste("target,
current differ in having response: ", :
the condition has length > 1 and only the first element will be used
> class(zz$formula)
[1] "pFormula" "Formula" "formula"
==
The last commands show that the warning message comes from comparing
the elements "formula", which are of the class "pFormula" (inheriting
from "Formula" and "formula"). It would be great if this issue could
be fixed in the future.
Thanks a lot,
Arne
--
Arne Henningsen
http://www.arne-henningsen.name
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Bug in all.equal() or in the plm package
Arne Henningsen wrote:
Hi!
I noticed that there is a (minor) bug either the command all.equal()
or in the "plm" package. I demonstrate this using an example taken
from the documentation of plm():
I'm not sure this is a bug, but I'd call it at least a design flaw. The
problem is that the length.Formula method in the Formula package (which
plm depends on) returns a vector of length 2. Now there's nothing in R
that requires length() to return a scalar, but all.equal assumes it
does, and I'd guess there are lots of other places this assumption is made.
Duncan Murdoch
==
R> data("Produc", package="plm")
R> zz <- plm(log(gsp)~log(pcap)+log(pc)+log(emp)+unemp,
+ data=Produc, index=c("state","year"))
R> all.equal(zz,zz)
[1] TRUE
Warning message:
In if (length(target) != length(current)) return(paste("target,
current differ in having response: ", :
the condition has length > 1 and only the first element will be used
all.equal(zz$formula,zz$formula)
[1] TRUE
Warning message:
In if (length(target) != length(current)) return(paste("target,
current differ in having response: ", :
the condition has length > 1 and only the first element will be used
class(zz$formula)
[1] "pFormula" "Formula" "formula"
==
The last commands show that the warning message comes from comparing
the elements "formula", which are of the class "pFormula" (inheriting
from "Formula" and "formula"). It would be great if this issue could
be fixed in the future.
Thanks a lot,
Arne
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] RcppTemplate
The Rcpp R/C++ object mapping library and package template has been updated on CRAN in package RcppTemplate. It allows you to work with R objects like data frames and zoo time series in C++ programs. R can call C++ functions, and C++ objects can call R functions, with parameters and return values of any of the most commonly used R data types (data frames, factors, time series, etc.). By using as.zoo, as.irts, as.xts, etc. it is possible to work with the other commonly used time series on the C++ side. The main design goal was improved performance. Dominick __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] \\signature macro generated by promptMethods
Hello,
promptMethods generate a macro for signatures, but the macro does not
exist in the Rd parser.
> setClass("track",
+ representation(x="numeric", y="numeric"))
[1] "track"
> setGeneric("foo", function(x){ standardGeneric("foo") } )
[1] "foo"
> setMethod( "foo", "track", function(x){ NULL } )
[1] "foo"
> promptMethods( "foo" )
A shell of methods documentation has been written to the file
‘foo-methods.Rd’.
> writeLines( readLines( "foo-methods.Rd" ) )
\name{foo-methods}
\docType{methods}
\alias{foo-methods}
\alias{foo,track-method}
\title{ ~~ Methods for Function foo ~~}
\description{
~~ Methods for function \code{foo} ~~
}
\section{Methods}{
\describe{
\item{\code{\signature(x = "track")}}{ ~~describe this method here }
}}
\keyword{methods}
\keyword{ ~~ other possible keyword(s)}
Romain
--
Romain Francois
Professional R Enthusiast
+33(0) 6 28 91 30 30
http://romainfrancois.blog.free.fr
|- http://tr.im/EAD5 : LondonR slides
|- http://tr.im/BcPw : celebrating R commit #5
`- http://tr.im/ztCu : RGG #158:161: examples of package IDPmisc
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] \\signature macro generated by promptMethods
On 09/11/2009 7:39 AM, Romain Francois wrote:
Hello,
promptMethods generate a macro for signatures, but the macro does not
exist in the Rd parser.
Right, that's not supposed to be a macro. See ?cbind2 for an example,
\item{\code{signature(x = "ANY", y = "ANY")}}{the default method
using \R's internal code.}
Duncan Murdoch
> setClass("track",
+ representation(x="numeric", y="numeric"))
[1] "track"
> setGeneric("foo", function(x){ standardGeneric("foo") } )
[1] "foo"
> setMethod( "foo", "track", function(x){ NULL } )
[1] "foo"
> promptMethods( "foo" )
A shell of methods documentation has been written to the file
‘foo-methods.Rd’.
> writeLines( readLines( "foo-methods.Rd" ) )
\name{foo-methods}
\docType{methods}
\alias{foo-methods}
\alias{foo,track-method}
\title{ ~~ Methods for Function foo ~~}
\description{
~~ Methods for function \code{foo} ~~
}
\section{Methods}{
\describe{
\item{\code{\signature(x = "track")}}{ ~~describe this method here }
}}
\keyword{methods}
\keyword{ ~~ other possible keyword(s)}
Romain
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] \\signature macro generated by promptMethods
On 11/9/2009 8:12 AM, Duncan Murdoch wrote:
On 09/11/2009 7:39 AM, Romain Francois wrote:
Hello,
promptMethods generate a macro for signatures, but the macro does not
exist in the Rd parser.
Right, that's not supposed to be a macro. See ?cbind2 for an example,
\item{\code{signature(x = "ANY", y = "ANY")}}{the default method
using \R's internal code.}
promptMethods() is now fixed in R-devel and R-patched.
Duncan Murdoch
Duncan Murdoch
> setClass("track",
+ representation(x="numeric", y="numeric"))
[1] "track"
> setGeneric("foo", function(x){ standardGeneric("foo") } )
[1] "foo"
> setMethod( "foo", "track", function(x){ NULL } )
[1] "foo"
> promptMethods( "foo" )
A shell of methods documentation has been written to the file
‘foo-methods.Rd’.
> writeLines( readLines( "foo-methods.Rd" ) )
\name{foo-methods}
\docType{methods}
\alias{foo-methods}
\alias{foo,track-method}
\title{ ~~ Methods for Function foo ~~}
\description{
~~ Methods for function \code{foo} ~~
}
\section{Methods}{
\describe{
\item{\code{\signature(x = "track")}}{ ~~describe this method here }
}}
\keyword{methods}
\keyword{ ~~ other possible keyword(s)}
Romain
__
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
[Rd] Alphanumeric tools::file_path_sans_ext() (PR#14050)
The file_path_sans_ext() function in the 'tools' package does not handle
alphanumeric file extensions correctly:
require(tools)
file_path_sans_ext("song.txt") # song, correct
file_path_sans_ext("song.mp3") # song.mp3, wrong
The help page states that "only purely alphanumeric extensions are
recognized", which I had expected. To fulfill this, the function body
should be
sub("([^.]+)\\.[[:alnum:]]+$", "\\1", x)
instead of the current definition:
sub("([^.]+)\\.[[:alpha:]]+$", "\\1", x)
Thanks,
Arni
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Negative integer subscripts in [[?
Should negative subscripts be outlawed in x[[subscript]] ? Currently, if subscript is a scalar then it can only be negative if length(x)==1 (otherwise [[ throws an error). If length(subscript)>1 then it gets treated as an attempt to recursively extract an element of a nested list. > list(10,20)[[-1]] # get the last element out of 2 [1] 20 > list(10,20,30)[[-(1:2)]] # get the last of 3? No. Error in list(10, 20, 30)[[-(1:2)]] : attempt to select more than one element > list(10,list(20,30))[[-c(1:2)]] # see how recursive subscripting is done [1] 20 If negative subscripts were not allowed in [[ then there might be a little less confusion about [[. (If recursive subscripting were done by a list instead of by an integer or character vector there might be less confusion and it would be more flexible.) Bill Dunlap Spotfire, TIBCO Software wdunlap tibco.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Negative integer subscripts in [[?
Hmm. It's something that is worth discouraging, because the user probably didn't mean it. But it is more or less consistent with the language, and prohibiting it at this date is unlikely to be worth the possible breakage (I know, who could possibly rely on it? But with a few thousand packages, somebody likely does.) John William Dunlap wrote: > Should negative subscripts be outlawed in >x[[subscript]] > ? > > Currently, if subscript is a scalar then it can only > be negative if length(x)==1 Actually, length(x)==2 as in your example. > (otherwise [[ throws an > error). If length(subscript)>1 then it gets treated > as an attempt to recursively extract an element of > a nested list. > Yes, but the interpretation is essentially consistent with multiple elements and positive values: > xx = list(c(1,2),c(3,4)) > xx[[-1]] [1] 3 4 > xx[[-2]] [1] 1 2 > xx[[c(-1,-2)]] [1] 3 > xx[[c(2,1)]] [1] 3 > >> list(10,20)[[-1]] # get the last element out of 2 >> > [1] 20 > >> list(10,20,30)[[-(1:2)]] # get the last of 3? No. >> > Error in list(10, 20, 30)[[-(1:2)]] : > attempt to select more than one element > >> list(10,list(20,30))[[-c(1:2)]] # see how recursive subscripting is >> > done > [1] 20 > > If negative subscripts were not allowed in [[ then > there might be a little less confusion about [[. > > (If recursive subscripting were done by a list instead > of by an integer or character vector there might be > less confusion and it would be more flexible.) > > > Bill Dunlap > Spotfire, TIBCO Software > wdunlap tibco.com > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > > [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] textConnection performance quadratic (PR#14053)
Full_Name: William E. Hopkins Version: 2.9.0 OS: Windows XP Submission from: (NULL) (209.244.4.106) textConnection() has quadratic performance. A function I wrote was taking outrageous amount of time to execute on a large character vector (small test set was used for functional development). I created a test harness to execute the function and gather stats (system.time) for various dataset sizes (datasets generated by sample() of very large set). If I used textConnection() to provide input to read.csv(), the performance was quadratic with dataset size. However, if I had the function write the character vector to a temp file then read the data back in via read.csv, the performance was linear. The reason for using a textConnection() was that the character vector was within a data frame read in via read.csv. The character vector (URLs) needed to be parsed into separate vectors, but no mechanism exists to do that directly (that I know of). So, I used sub() to extract the proper pieces and put commas in between so that I can use read.csv() to read the comma-separate strings directly into vectors. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] textConnection performance quadratic (PR#14053)
strsplit can split by separators and strapply in the gsubfn package can split by content. On Mon, Nov 9, 2009 at 6:40 PM, wrote: > Full_Name: William E. Hopkins > Version: 2.9.0 > OS: Windows XP > Submission from: (NULL) (209.244.4.106) > > > textConnection() has quadratic performance. > > A function I wrote was taking outrageous amount of time to execute on a large > character vector (small test set was used for functional development). I > created > a test harness to execute the function and gather stats (system.time) for > various dataset sizes (datasets generated by sample() of very large set). If I > used textConnection() to provide input to read.csv(), the performance was > quadratic with dataset size. However, if I had the function write the > character > vector to a temp file then read the data back in via read.csv, the performance > was linear. > > The reason for using a textConnection() was that the character vector was > within > a data frame read in via read.csv. The character vector (URLs) needed to be > parsed into separate vectors, but no mechanism exists to do that directly > (that > I know of). So, I used sub() to extract the proper pieces and put commas in > between so that I can use read.csv() to read the comma-separate strings > directly > into vectors. > > __ > 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] Negative integer subscripts in [[?
On 09/11/2009 4:38 PM, William Dunlap wrote: Should negative subscripts be outlawed in x[[subscript]] ? Currently, if subscript is a scalar then it can only be negative if length(x)==1 (otherwise [[ throws an error). If length(subscript)>1 then it gets treated as an attempt to recursively extract an element of a nested list. list(10,20)[[-1]] # get the last element out of 2 [1] 20 list(10,20,30)[[-(1:2)]] # get the last of 3? No. Error in list(10, 20, 30)[[-(1:2)]] : attempt to select more than one element list(10,list(20,30))[[-c(1:2)]] # see how recursive subscripting is done [1] 20 If negative subscripts were not allowed in [[ then there might be a little less confusion about [[. I agree, it would be better not to allow negatives here, but as John said it's probably too late to do away with them. (If recursive subscripting were done by a list instead of by an integer or character vector there might be less confusion and it would be more flexible.) I don't follow this. Recursive lists are trees, and you specify a single element of a tree by specifying a sequence of indices. Why would it be less confusing to give a list? What extra flexibility could there be? I suppose you could mix integer and character indices, but what would be meant by x[[ list(1, list(2,3), 4) ]] ? I don't know the original motivation for allowing vector indexing to lists, but I extended it to pairlists so that it would be possible to specify a location within a function exactly, by walking down the parse tree. I think it's something that would be rarely used, but when you need it, it's very handy. Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Negative integer subscripts in [[?
> -Original Message-
> From: Duncan Murdoch [mailto:murd...@stats.uwo.ca]
> Sent: Monday, November 09, 2009 4:55 PM
> To: William Dunlap
> Cc: r-devel@r-project.org
> Subject: Re: [Rd] Negative integer subscripts in [[?
>
> On 09/11/2009 4:38 PM, William Dunlap wrote:
> > Should negative subscripts be outlawed in
> >x[[subscript]]
> > ?
> >
> > Currently, if subscript is a scalar then it can only
> > be negative if length(x)==1 (otherwise [[ throws an
Oops, I meant: length(x)==2
> > error). If length(subscript)>1 then it gets treated
> > as an attempt to recursively extract an element of
> > a nested list.
> >
> >> list(10,20)[[-1]] # get the last element out of 2
> > [1] 20
> >> list(10,20,30)[[-(1:2)]] # get the last of 3? No.
> > Error in list(10, 20, 30)[[-(1:2)]] :
> > attempt to select more than one element
> >> list(10,list(20,30))[[-c(1:2)]] # see how recursive subscripting is
> > done
> > [1] 20
> >
> > If negative subscripts were not allowed in [[ then
> > there might be a little less confusion about [[.
>
> I agree, it would be better not to allow negatives here, but as John
> said it's probably too late to do away with them.
>
> > (If recursive subscripting were done by a list instead
> > of by an integer or character vector there might be
> > less confusion and it would be more flexible.)
>
> I don't follow this. Recursive lists are trees, and you specify a
> single element of a tree by specifying a sequence of indices.
> Why would
> it be less confusing to give a list? What extra flexibility
> could there
> be? I suppose you could mix integer and character indices, but what
> would be meant by x[[ list(1, list(2,3), 4) ]] ?
It would allow mixed integer, character, and logical indices
and, since lists are not allowed for other forms of subscripts,
it would make it clear that you wanted a recursive subcript.
At each level you would have to select just one element, just as is
the restriction now.
E.g., now we do
x <- list(A=list(10,20), B=list(B1=30, B2=40))
x[[c(1,2)]] # gives 20
but this could be done as
x[[list(1,2)]]
or
x[[list("A",2)]]
or
x[[list(c(TRUE,FALSE), -1)]]
It would mean that the following 2 functions would return the
same result
f1 <- function(x, subscriptList) x[[subscriptList]]
f2 <- function(x, subscriptList) {
for(i in subscriptList)
x <- x[[i]] # or x[i][[1]] to handle logical subscripts
x
}
when subscriptList is a list. Currently they return the same
when subscriptList is an integer vector.
> I don't know the original motivation for allowing vector indexing to
> lists, but I extended it to pairlists so that it would be possible to
> specify a location within a function exactly, by walking down
> the parse
> tree. I think it's something that would be rarely used, but when you
> need it, it's very handy.
That is the sort of thing I've used it for, rarely.
We can always change the logical and character vectors
into integers so it isn't a big deal. I was more concerned
by folks accidently using [[ with a vector subscript where [
was appropriate and getting a mysterious error message or
the wrong answer from the unintended recursive subscript.
However, it is far too late to get rid of the integer vector
version of it.
Bill Dunlap
Spotfire, TIBCO Software
wdunlap tibco.com
>
> Duncan Murdoch
>
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Regression: PR#9602 - bquote(function(x,y) T)
Dear R developers, PR#9602 is currently marked as "Low-level-fixed". Yet I have been caught by it on R-2.10.0 (see below). Thanks in advance! Best regards, Pascal Hirsch > quote(function(x, y) T) function(x, y) T > bquote(function(x, y) T) function(, y) T > eval(.Last.value) Error in eval(expr, envir, enclos) : invalid formal argument list for "function" > R.version _ platform i386-pc-mingw32 arch i386 os mingw32 system i386, mingw32 status Patched major 2 minor 10.0 year 2009 month 10 day26 svn rev50212 language R version.string R version 2.10.0 Patched (2009-10-26 r50212) __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Windows installer, HTML help, R 2.10.0
I'm not 100% sure this hasn't been covered already (I searched a bit, but I had a little trouble filtering down to a useful number of useful results). Anyway, when I install R on Windows, the installer asks to set the default help type. For some reason, I can set it as HTML in the installer, but the results open as if help_type = "text" by default. I presume this is related to the new changes to the help. Calling help(help, help_type = "html") works as expected, so the HTML help works and I could manually fix this by setting options(help_type = "html") in a session or in my .Rprofile. I'm not sure if I'm the only one seeing this, but for what it's worth, I also set SDI and Internet = Standard. I haven't experimented with different installation settings to see which ones work. Oliver __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Windows installer, HTML help, R 2.10.0
On Tue, Nov 10, 2009 at 10:35 AM, Oliver Soong wrote: > I'm not 100% sure this hasn't been covered already (I searched a bit, > but I had a little trouble filtering down to a useful number of useful > results). It has, see http://old.nabble.com/Cannot-activate-chm-help-in-R-2.10-td26067423.html -Deepayan > Anyway, when I install R on Windows, the installer asks to > set the default help type. For some reason, I can set it as HTML in > the installer, but the results open as if help_type = "text" by > default. I presume this is related to the new changes to the help. > Calling help(help, help_type = "html") works as expected, so the HTML > help works and I could manually fix this by setting options(help_type > = "html") in a session or in my .Rprofile. > > I'm not sure if I'm the only one seeing this, but for what it's worth, > I also set SDI and Internet = Standard. I haven't experimented with > different installation settings to see which ones work. > > Oliver > > __ > 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
