[Rd] package "signal", function "filter" (PR#12752)
Full_Name: Jeff Schenck Version: 2.6.2 (signal v. 0.5) OS: Windows XP Submission from: (NULL) (128.107.248.220) The "filter" function in the package "signal" does not properly handle recursive filters with only two feedback taps. I looked at the source code in filter.R. There is a line that says "if (length(a) > 2)" that I think should have ">=". I tried it that way and it seems to work fine. FYI... My test filter was a DC notch: b <- c(1, -1) a <- c(1, -0.95) y <- filter(b, a, x) Thanks, Jeff Schenck __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] package "signal", function "filter" (PR#12752)
Package 'signal' is not the responsibility of the R developers, so you need to follow the FAQ and report this to the maintainer, rather than clog up R-bgs with an inappopriate report. You might find that R's own function filter() is better written. The FAQ also asks you not to report on long obsolete versions of R. On Tue, 9 Sep 2008, [EMAIL PROTECTED] wrote: > Full_Name: Jeff Schenck > Version: 2.6.2 (signal v. 0.5) > OS: Windows XP > Submission from: (NULL) (128.107.248.220) > > > The "filter" function in the package "signal" does not properly handle > recursive > filters with only two feedback taps. I looked at the source code in filter.R. > There is a line that says "if (length(a) > 2)" that I think should have ">=". > I > tried it that way and it seems to work fine. > > FYI... My test filter was a DC notch: > b <- c(1, -1) > a <- c(1, -0.95) > y <- filter(b, a, x) > > Thanks, > Jeff Schenck > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > -- Brian D. Ripley, [EMAIL PROTECTED] Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/ University of Oxford, Tel: +44 1865 272861 (self) 1 South Parks Road, +44 1865 272866 (PA) Oxford OX1 3TG, UKFax: +44 1865 272595 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] package "signal", function "filter" (PR#12752)
On Tue, Sep 9, 2008 at 2:30 AM, <[EMAIL PROTECTED]> wrote: > Package 'signal' is not the responsibility of the R developers, so you > need to follow the FAQ and report this to the maintainer, rather than > clog up R-bgs with an inappopriate report. > > You might find that R's own function filter() is better written. > > The FAQ also asks you not to report on long obsolete versions of R. Perhaps if these frequently "asked" questions were actually displayed on the bug reporting page people would notice them. Hadley -- http://had.co.nz/ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] 'xtfrm' performance (influences 'order' performance) in R devel
Hello everybody,
it looks like the presense of some (do know know which) S4 methods for a
given S4 class degrades the performance of xtfrm (used in 'order' in new
R-devel) by a factor of millions. This is for classes that ARE derived
from numeric directly and thus should be quite trivial to convert to
numeric.
Consider the following example:
setClass("TimeDateBase",
representation("numeric", mode="character"),
prototype(mode="posix")
)
setClass("TimeDate",
representation("TimeDateBase", tzone="character"),
prototype(tzone="London")
)
x = new("TimeDate", 1220966224 + runif(1e5))
system.time({ z = order(x) })
## > system.time({ z = order(x) })
## user system elapsed
## 0.048 0.000 0.048
getClass("TimeDate")
## Class "TimeDate"
## Slots:
## Name: .Data tzone mode
## Class: numeric character character
## Extends:
## Class "TimeDateBase", directly
## Class "numeric", by class "TimeDateBase", distance 2
## Class "vector", by class "TimeDateBase", distance 3
Now, if I load a library that not only defines these same classes, but
also a bunch of methods for those, then I have the following result:
library(AHLCalendar)
x = now() + runif(1e5) ## just random times in POSIXct format
x[1:5]
## TimeDate [posix] object in 'Europe/London' of length 5:
## [1] "2008-09-09 14:19:35.218" "2008-09-09 14:19:35.672"
## [3] "2008-09-09 14:19:35.515" "2008-09-09 14:19:35.721"
## [5] "2008-09-09 14:19:35.657"
> system.time({ z = order(x) })
Enter a frame number, or 0 to exit
1: system.time({
2: order(x)
3: lapply(z, function(x) if (is.object(x)) xtfrm(x) else x)
4: FUN(X[[1]], ...)
5: xtfrm(x)
6: xtfrm.default(x)
7: as.vector(rank(x, ties.method = "min", na.last = "keep"))
8: rank(x, ties.method = "min", na.last = "keep")
9: switch(ties.method, average = , min = , max =
.Internal(rank(x[!nas], ties.
10: .gt(c(1220966375.21811, 1220966375.67217, 1220966375.51470,
1220966375.7211
11: x[j]
12: x[j]
Selection: 0
Timing stopped at: 47.618 13.791 66.478
At the same time:
system.time({ z = as.numeric(x) }) ## same as [EMAIL PROTECTED]
## user system elapsed
## 0.001 0.000 0.001
The only difference between the two is that I have the following methods
defined for TimeDate (full listing below).
Any idea why this could be happenning. And yes, it is down to xtfrm
function, 'order' was just a place where the problem occured. Should
xtfrm function be smarter with respect to classes that are actually
derived from 'numeric'?
> showMethods(class="TimeDate")
Function: + (package base)
e1="TimeDate", e2="TimeDate"
e1="TimeDate", e2="numeric"
(inherited from: e1="TimeDateBase", e2="numeric")
Function: - (package base)
e1="TimeDate", e2="TimeDate"
Function: Time (package AHLCalendar)
x="TimeDate"
Function: TimeDate (package AHLCalendar)
x="TimeDate"
Function: TimeDate<- (package AHLCalendar)
x="TimeSeries", value="TimeDate"
Function: TimeSeries (package AHLCalendar)
x="data.frame", ts="TimeDate"
x="matrix", ts="TimeDate"
x="numeric", ts="TimeDate"
Function: [ (package base)
x="TimeDate", i="POSIXt", j="missing"
x="TimeDate", i="Time", j="missing"
x="TimeDate", i="TimeDate", j="missing"
x="TimeDate", i="integer", j="missing"
(inherited from: x="TimeDateBase", i="ANY", j="missing")
x="TimeDate", i="logical", j="missing"
(inherited from: x="TimeDateBase", i="ANY", j="missing")
x="TimeSeries", i="TimeDate", j="missing"
x="TimeSeries", i="TimeDate", j="vector"
Function: [<- (package base)
x="TimeDate", i="ANY", j="ANY", value="ANY"
x="TimeDate", i="ANY", j="ANY", value="numeric"
x="TimeDate", i="missing", j="ANY", value="ANY"
x="TimeDate", i="missing", j="ANY", value="numeric"
Function: add (package AHLCalendar)
x="TimeDate"
Function: addMonths (package AHLCalendar)
x="TimeDate"
Function: addYears (package AHLCalendar)
x="TimeDate"
Function: align (package AHLCalendar)
x="TimeDate", to="character"
x="TimeDate", to="missing"
Function: as.POSIXct (package base)
x="TimeDate"
Function: as.POSIXlt (package base)
x="TimeDate"
Function: coerce (package methods)
from="TimeDate", to="TimeDateBase"
Function: coerce<- (package methods)
from="TimeDate", to="numeric"
Function: dates (package AHLCalendar)
x="TimeDate"
Function: format (package base)
x="TimeDate"
Function: fxFwdDate (package AHLCalendar)
x="TimeDate", country="character"
Function: fxSettleDate (package AHLCalendar)
x="TimeDate", country="character"
Function: holidays (package AHLCalendar)
x="TimeDate"
Function: index (package AHLCalendar)
x="TimeDate", y="POSIXt"
x="TimeDate", y="Time"
x="TimeDate", y="TimeDate"
Function: initialize (package methods)
.Object="TimeDate"
(inherited from: .Object="ANY")
Function: leapYear (package AHLCalendar)
x="TimeDate"
Function: mday (package AHLCalendar)
x="TimeDate"
Function: mode (package base)
x="TimeDate"
(inherited from: x="TimeDateBase")
Function: mode<- (package base)
x="TimeDate", value="charact
[Rd] legend does not reset xpd (PR#12756)
Full_Name: Mark Difford
Version: R version 2.7.2 Patched (2008-08-26 r46442)
OS: Windows -- Vista
Submission from: (NULL) (198.54.202.146)
legend(graphics) does not reset xpd to its pre-call state when it has finished
drawing the legend.
## Ex.
par(xpd = FALSE)
plot(1)
legend("top", legend="Tops", xpd=NA, inset=c(-.1))
plot(1); abline(v=1); par(xpd=FALSE)
plot(1)
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Addendum to wishlist bug report #10931 (factanal) (PR#12754)
--=-hiYzUeWcRJ/+kx41aPIZ
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
Hi,
on March 10 I filed a wishlist bug report asking for the inclusion of
some changes to factanal() and the associated print method. The changes
were originally proposed by John Fox in 2005; they make print.factanal()
display factor correlations if factanal() is called with rotation =
"promax". Since I got no replies, and I am really tired of my R-curious
social science colleagues asking "What, it can't even display factor
correlations?!", I made the changes myself. I would be very grateful if
they'd find their way into a release.
I corrected a small error in John Fox's code and made another change
that enables factor correlations not only for promax, but also for the
rotation methods in package GPArotation.
The changes are against R-devel, downloaded on September 9th 2008.
Changes are indicated by comments from John Fox and me. I also changed
factanal.Rd accordingly, this is commented too.
My bug report is at
http://bugs.r-project.org/cgi-bin/R/wishlist?id=10931;user=guest
John Fox's original post is at
http://tolstoy.newcastle.edu.au/R/devel/05/06/1414.html
The changed files factanal.R and factanal.Rd are attached. If there is
anything else I can do to help these changes make it into R, please let
me know.
Thanks and best regards,
Uli
--
Ulrich Keller
Université du Luxembourg
EMACS research unit
B.P. 2
L-7201 Walferdange
Luxembourg
Mail [EMAIL PROTECTED]
Phone +352 46 66 44 9 278
--=-hiYzUeWcRJ/+kx41aPIZ
Content-Disposition: attachment; filename="factanal.R"
Content-Type: text/plain; name="factanal.R"; charset="utf-8"
Content-Transfer-Encoding: 7bit
# File src/library/stats/R/factanal.R
# Part of the R package, http://www.R-project.org
#
# This program is free software; you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
# the Free Software Foundation; either version 2 of the License, or
# (at your option) any later version.
#
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
# GNU General Public License for more details.
#
# A copy of the GNU General Public License is available at
# http://www.r-project.org/Licenses/
## Hmm, MM thinks diag(.) needs checking { diag(vec) when length(vec)==1 !}
## However, MM does not understand that factor analysis
## is a *multi*variate technique!
factanal <-
function (x, factors, data = NULL, covmat = NULL, n.obs = NA,
subset, na.action, start = NULL,
scores = c("none", "regression", "Bartlett"),
rotation = "varimax",
control = NULL, ...)
{
sortLoadings <- function(Lambda)
{
cn <- colnames(Lambda)
Phi <- attr(Lambda, "covariance")
ssq <- apply(Lambda, 2, function(x) -sum(x^2))
Lambda <- Lambda[, order(ssq), drop = FALSE]
colnames(Lambda) <- cn
neg <- colSums(Lambda) < 0
Lambda[, neg] <- -Lambda[, neg]
if(!is.null(Phi)) {
unit <- ifelse(neg, -1, 1)
attr(Lambda, "covariance") <-
unit %*% Phi[order(ssq), order(ssq)] %*% unit
}
Lambda
}
cl <- match.call()
na.act <- NULL
if (is.list(covmat)) {
if (any(is.na(match(c("cov", "n.obs"), names(covmat)
stop("'covmat' is not a valid covariance list")
cv <- covmat$cov
n.obs <- covmat$n.obs
have.x <- FALSE
}
else if (is.matrix(covmat)) {
cv <- covmat
have.x <- FALSE
}
else if (is.null(covmat)) {
if(missing(x)) stop("neither 'x' nor 'covmat' supplied")
have.x <- TRUE
if(inherits(x, "formula")) {
## this is not a `standard' model-fitting function,
## so no need to consider contrasts or levels
mt <- terms(x, data = data)
if(attr(mt, "response") > 0)
stop("response not allowed in formula")
attr(mt, "intercept") <- 0
mf <- match.call(expand.dots = FALSE)
names(mf)[names(mf) == "x"] <- "formula"
mf$factors <- mf$covmat <- mf$scores <- mf$start <-
mf$rotation <- mf$control <- mf$... <- NULL
mf[[1]] <- as.name("model.frame")
mf <- eval.parent(mf)
na.act <- attr(mf, "na.action")
if (.check_vars_numeric(mf))
stop("factor analysis applies only to numerical variables")
z <- model.matrix(mt, mf)
} else {
z <- as.matrix(x)
if(!is.numeric(z))
stop("factor analysis applies only to numerical variables")
if(!missing(subset)) z <- z[subset, , drop = FALSE]
}
covmat <- cov.wt(z)
cv <- covmat$cov
n.obs <- covmat$n.obs
}
else stop(
Re: [Rd] 'xtfrm' performance (influences 'order' performance) in R devel
No definitive answers, but here are a few observations.
In the call to order() code, I notice that you have dropped into the branch
if (any(unlist(lapply(z, is.object
where the alternative in your case would seem to have been going
directly to the internal code.
You can consider a method for xtfrm(), which would help but won't get
you completely back to a trivial computation. Alternatively, order()
should be eligible for the new mechanism of defining methods for "...".
(Individual existing methods may not be the issue, and one can't infer
anything definite from the evidence given, but a plausible culprit is
the "[" method. Because [] expressions appear so often, it's always
chancy to define a nontrivial method for this function.)
John
Sklyar, Oleg (London) wrote:
> Hello everybody,
>
> it looks like the presense of some (do know know which) S4 methods for a
> given S4 class degrades the performance of xtfrm (used in 'order' in new
> R-devel) by a factor of millions. This is for classes that ARE derived
> from numeric directly and thus should be quite trivial to convert to
> numeric.
>
> Consider the following example:
>
> setClass("TimeDateBase",
> representation("numeric", mode="character"),
> prototype(mode="posix")
> )
> setClass("TimeDate",
> representation("TimeDateBase", tzone="character"),
> prototype(tzone="London")
> )
> x = new("TimeDate", 1220966224 + runif(1e5))
>
> system.time({ z = order(x) })
> ## > system.time({ z = order(x) })
> ## user system elapsed
> ## 0.048 0.000 0.048
>
> getClass("TimeDate")
> ## Class "TimeDate"
>
> ## Slots:
>
> ## Name: .Data tzone mode
> ## Class: numeric character character
>
> ## Extends:
> ## Class "TimeDateBase", directly
> ## Class "numeric", by class "TimeDateBase", distance 2
> ## Class "vector", by class "TimeDateBase", distance 3
>
>
> Now, if I load a library that not only defines these same classes, but
> also a bunch of methods for those, then I have the following result:
>
> library(AHLCalendar)
> x = now() + runif(1e5) ## just random times in POSIXct format
> x[1:5]
> ## TimeDate [posix] object in 'Europe/London' of length 5:
> ## [1] "2008-09-09 14:19:35.218" "2008-09-09 14:19:35.672"
> ## [3] "2008-09-09 14:19:35.515" "2008-09-09 14:19:35.721"
> ## [5] "2008-09-09 14:19:35.657"
>
>
>> system.time({ z = order(x) })
>>
>
>
> Enter a frame number, or 0 to exit
>
> 1: system.time({
> 2: order(x)
> 3: lapply(z, function(x) if (is.object(x)) xtfrm(x) else x)
> 4: FUN(X[[1]], ...)
> 5: xtfrm(x)
> 6: xtfrm.default(x)
> 7: as.vector(rank(x, ties.method = "min", na.last = "keep"))
> 8: rank(x, ties.method = "min", na.last = "keep")
> 9: switch(ties.method, average = , min = , max =
> .Internal(rank(x[!nas], ties.
> 10: .gt(c(1220966375.21811, 1220966375.67217, 1220966375.51470,
> 1220966375.7211
> 11: x[j]
> 12: x[j]
>
> Selection: 0
> Timing stopped at: 47.618 13.791 66.478
>
> At the same time:
>
> system.time({ z = as.numeric(x) }) ## same as [EMAIL PROTECTED]
> ## user system elapsed
> ## 0.001 0.000 0.001
>
> The only difference between the two is that I have the following methods
> defined for TimeDate (full listing below).
>
> Any idea why this could be happenning. And yes, it is down to xtfrm
> function, 'order' was just a place where the problem occured. Should
> xtfrm function be smarter with respect to classes that are actually
> derived from 'numeric'?
>
>
>> showMethods(class="TimeDate")
>>
> Function: + (package base)
> e1="TimeDate", e2="TimeDate"
> e1="TimeDate", e2="numeric"
> (inherited from: e1="TimeDateBase", e2="numeric")
>
> Function: - (package base)
> e1="TimeDate", e2="TimeDate"
>
> Function: Time (package AHLCalendar)
> x="TimeDate"
>
> Function: TimeDate (package AHLCalendar)
> x="TimeDate"
>
> Function: TimeDate<- (package AHLCalendar)
> x="TimeSeries", value="TimeDate"
>
> Function: TimeSeries (package AHLCalendar)
> x="data.frame", ts="TimeDate"
> x="matrix", ts="TimeDate"
> x="numeric", ts="TimeDate"
>
> Function: [ (package base)
> x="TimeDate", i="POSIXt", j="missing"
> x="TimeDate", i="Time", j="missing"
> x="TimeDate", i="TimeDate", j="missing"
> x="TimeDate", i="integer", j="missing"
> (inherited from: x="TimeDateBase", i="ANY", j="missing")
> x="TimeDate", i="logical", j="missing"
> (inherited from: x="TimeDateBase", i="ANY", j="missing")
> x="TimeSeries", i="TimeDate", j="missing"
> x="TimeSeries", i="TimeDate", j="vector"
>
> Function: [<- (package base)
> x="TimeDate", i="ANY", j="ANY", value="ANY"
> x="TimeDate", i="ANY", j="ANY", value="numeric"
> x="TimeDate", i="missing", j="ANY", value="ANY"
> x="TimeDate", i="missing", j="ANY", value="numeric"
>
> Function: add (package AHLCalendar)
> x="TimeDate"
>
> Function: addMonths (package AHLCalendar)
> x="TimeDate"
>
> Function: addYears (package AHLCalendar)
> x="TimeDate"
>
> Function: align (package AHLCalendar)
Re: [Rd] 'xtfrm' performance (influences 'order' performance) in R devel
Thanks for a quick reply, I was thinking of [ methods myself, but there
are so many of them. I only tested [(x=TimeDate,i=TimeDate,j=missing),
which is a completely non-standard one. It did not seem to have any
effect though.
I was thinking of writing the 'order' method and will experiment with
getting the one for xtfrm. However, it seems reasonable for the default
xtfrm to check if the object is inherited from a vector and in that case
simply returning the .Data slot? This would solve this and similar cases
immediately:
if (inherits(x,"vector")) return(as.vector([EMAIL PROTECTED]))
BTW, generally, xtfrm.default calls 'rank' and it is not clear why rank
should work for a generic S4 object... this is essentially where the
problem is.
On a side note, a week ago I submitted a patch for the plot.default to
Rd, but nobody reacted (I checked the most recent patched and devel as
well) -- it is really an ugly bug (e.g
plot(1:5,1:5,xlim=c(-10,10),ylim=c(-8,3)) ) and the trivial patch fixes
it. Would be grateful if somebody from R-core checks it up. Meanwhile I
patch the graphics library before compiling R, which is not the best
solution. Here is the patch for src/library/graphics/plot.R
70,71c70,71
< localAxis(if(is.null(y)) xy$x else x, side = 1, ...)
< localAxis(if(is.null(y)) x else y, side = 2, ...)
---
> localAxis(xlim, side = 1, ...)
> localAxis(ylim, side = 2, ...)
Dr Oleg Sklyar
Research Technologist
AHL / Man Investments Ltd
+44 (0)20 7144 3107
[EMAIL PROTECTED]
> -Original Message-
> From: John Chambers [mailto:[EMAIL PROTECTED]
> Sent: 09 September 2008 15:11
> To: Sklyar, Oleg (London)
> Cc: R-devel@r-project.org
> Subject: Re: [Rd] 'xtfrm' performance (influences 'order'
> performance) in R devel
>
> No definitive answers, but here are a few observations.
>
> In the call to order() code, I notice that you have dropped
> into the branch
> if (any(unlist(lapply(z, is.object
> where the alternative in your case would seem to have been
> going directly to the internal code.
>
> You can consider a method for xtfrm(), which would help but
> won't get you completely back to a trivial computation.
> Alternatively, order() should be eligible for the new
> mechanism of defining methods for "...".
>
> (Individual existing methods may not be the issue, and one
> can't infer anything definite from the evidence given, but a
> plausible culprit is the "[" method. Because [] expressions
> appear so often, it's always chancy to define a nontrivial
> method for this function.)
>
> John
>
> Sklyar, Oleg (London) wrote:
>
> Hello everybody,
>
> it looks like the presense of some (do know know which)
> S4 methods for a
> given S4 class degrades the performance of xtfrm (used
> in 'order' in new
> R-devel) by a factor of millions. This is for classes
> that ARE derived
> from numeric directly and thus should be quite trivial
> to convert to
> numeric.
>
> Consider the following example:
>
> setClass("TimeDateBase",
> representation("numeric", mode="character"),
> prototype(mode="posix")
> )
> setClass("TimeDate",
> representation("TimeDateBase", tzone="character"),
> prototype(tzone="London")
> )
> x = new("TimeDate", 1220966224 + runif(1e5))
>
> system.time({ z = order(x) })
> ## > system.time({ z = order(x) })
> ## user system elapsed
> ## 0.048 0.000 0.048
>
> getClass("TimeDate")
> ## Class "TimeDate"
>
> ## Slots:
>
> ## Name: .Data tzone mode
> ## Class: numeric character character
>
> ## Extends:
> ## Class "TimeDateBase", directly
> ## Class "numeric", by class "TimeDateBase", distance 2
> ## Class "vector", by class "TimeDateBase", distance 3
>
>
> Now, if I load a library that not only defines these
> same classes, but
> also a bunch of methods for those, then I have the
> following result:
>
> library(AHLCalendar)
> x = now() + runif(1e5) ## just random times in POSIXct format
> x[1:5]
> ## TimeDate [posix] object in 'Europe/London' of length 5:
> ## [1] "2008-09-09 14:19:35.218" "2008-09-09 14:19:35.672"
> ## [3] "2008-09-09 14:19:35.515" "2008-09-09 14:19:35.721"
> ## [5] "2008-09-09 14:19:35.657"
>
>
>
> system.time({ z = order(x) })
>
>
>
>
> Enter a frame number, or 0 to exit
>
>1: system.time({
>2: order(x)
>3: lapply(z, function(x) if (is.object(x)) xtfrm(x) else x)
>4: FUN(X[[1]], ...)
>5: xtfrm(x)
>6: xtfrm.default(x)
>7: as.vector(rank(x, ties.method = "min", na.last = "keep"))
>8: rank(x, ties.me
Re: [Rd] 'xtfrm' performance (influences 'order' performance) in R devel
Ha, defined xtfrm for TimeDate, works instantly (xtfrm is already a
method). However, it won't be taken up by order as it is not in the
imported namespace, so order falls back to xtfrm.default.
Moreover, defining order (which is not a method unfortunately, *any
chance of changing this*?):
setGeneric("order")
setMethod("order", "TimeDate",
function (..., na.last = TRUE, decreasing = FALSE)
order(list(...)[EMAIL PROTECTED],na.last=na.last,
decreasing=decreasing))
does not help either as it won't be taken up, order still calls the
default one, what am I doing wrong?
Dr Oleg Sklyar
Research Technologist
AHL / Man Investments Ltd
+44 (0)20 7144 3107
[EMAIL PROTECTED]
> -Original Message-
> From: John Chambers [mailto:[EMAIL PROTECTED]
> Sent: 09 September 2008 15:11
> To: Sklyar, Oleg (London)
> Cc: R-devel@r-project.org
> Subject: Re: [Rd] 'xtfrm' performance (influences 'order'
> performance) in R devel
>
> No definitive answers, but here are a few observations.
>
> In the call to order() code, I notice that you have dropped
> into the branch
> if (any(unlist(lapply(z, is.object
> where the alternative in your case would seem to have been
> going directly to the internal code.
>
> You can consider a method for xtfrm(), which would help but
> won't get you completely back to a trivial computation.
> Alternatively, order() should be eligible for the new
> mechanism of defining methods for "...".
>
> (Individual existing methods may not be the issue, and one
> can't infer anything definite from the evidence given, but a
> plausible culprit is the "[" method. Because [] expressions
> appear so often, it's always chancy to define a nontrivial
> method for this function.)
>
> John
>
> Sklyar, Oleg (London) wrote:
>
> Hello everybody,
>
> it looks like the presense of some (do know know which)
> S4 methods for a
> given S4 class degrades the performance of xtfrm (used
> in 'order' in new
> R-devel) by a factor of millions. This is for classes
> that ARE derived
> from numeric directly and thus should be quite trivial
> to convert to
> numeric.
>
> Consider the following example:
>
> setClass("TimeDateBase",
> representation("numeric", mode="character"),
> prototype(mode="posix")
> )
> setClass("TimeDate",
> representation("TimeDateBase", tzone="character"),
> prototype(tzone="London")
> )
> x = new("TimeDate", 1220966224 + runif(1e5))
>
> system.time({ z = order(x) })
> ## > system.time({ z = order(x) })
> ## user system elapsed
> ## 0.048 0.000 0.048
>
> getClass("TimeDate")
> ## Class "TimeDate"
>
> ## Slots:
>
> ## Name: .Data tzone mode
> ## Class: numeric character character
>
> ## Extends:
> ## Class "TimeDateBase", directly
> ## Class "numeric", by class "TimeDateBase", distance 2
> ## Class "vector", by class "TimeDateBase", distance 3
>
>
> Now, if I load a library that not only defines these
> same classes, but
> also a bunch of methods for those, then I have the
> following result:
>
> library(AHLCalendar)
> x = now() + runif(1e5) ## just random times in POSIXct format
> x[1:5]
> ## TimeDate [posix] object in 'Europe/London' of length 5:
> ## [1] "2008-09-09 14:19:35.218" "2008-09-09 14:19:35.672"
> ## [3] "2008-09-09 14:19:35.515" "2008-09-09 14:19:35.721"
> ## [5] "2008-09-09 14:19:35.657"
>
>
>
> system.time({ z = order(x) })
>
>
>
>
> Enter a frame number, or 0 to exit
>
>1: system.time({
>2: order(x)
>3: lapply(z, function(x) if (is.object(x)) xtfrm(x) else x)
>4: FUN(X[[1]], ...)
>5: xtfrm(x)
>6: xtfrm.default(x)
>7: as.vector(rank(x, ties.method = "min", na.last = "keep"))
>8: rank(x, ties.method = "min", na.last = "keep")
>9: switch(ties.method, average = , min = , max =
> .Internal(rank(x[!nas], ties.
> 10: .gt(c(1220966375.21811, 1220966375.67217, 1220966375.51470,
> 1220966375.7211
> 11: x[j]
> 12: x[j]
>
> Selection: 0
> Timing stopped at: 47.618 13.791 66.478
>
> At the same time:
>
> system.time({ z = as.numeric(x) }) ## same as [EMAIL PROTECTED]
> ## user system elapsed
> ## 0.001 0.000 0.001
>
> The only difference between the two is that I have the
> following methods
> defined for TimeDate (full listing below).
>
> Any idea why this could be happenning. And yes, it is
> down to xtfrm
> function, 'order' was just a place where the problem
> occur
Re: [Rd] Addendum to wishlist bug report #10931 (factanal) (PR#12754)
Dear Ulrich,
I'd frankly forgotten about this, but can't see an argument for not making
this (or a similar) change.
Thanks for reviving the issue.
John
--
John Fox, Professor
Department of Sociology
McMaster University
Hamilton, Ontario, Canada
web: socserv.mcmaster.ca/jfox
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
On
> Behalf Of [EMAIL PROTECTED]
> Sent: September-09-08 7:55 AM
> To: [EMAIL PROTECTED]
> Cc: [EMAIL PROTECTED]
> Subject: [Rd] Addendum to wishlist bug report #10931 (factanal) (PR#12754)
>
> --=-hiYzUeWcRJ/+kx41aPIZ
> Content-Type: text/plain; charset="UTF-8"
> Content-Transfer-Encoding: 8bit
>
> Hi,
>
> on March 10 I filed a wishlist bug report asking for the inclusion of
> some changes to factanal() and the associated print method. The changes
> were originally proposed by John Fox in 2005; they make print.factanal()
> display factor correlations if factanal() is called with rotation =
> "promax". Since I got no replies, and I am really tired of my R-curious
> social science colleagues asking "What, it can't even display factor
> correlations?!", I made the changes myself. I would be very grateful if
> they'd find their way into a release.
>
> I corrected a small error in John Fox's code and made another change
> that enables factor correlations not only for promax, but also for the
> rotation methods in package GPArotation.
>
> The changes are against R-devel, downloaded on September 9th 2008.
> Changes are indicated by comments from John Fox and me. I also changed
> factanal.Rd accordingly, this is commented too.
>
> My bug report is at
> http://bugs.r-project.org/cgi-bin/R/wishlist?id=10931;user=guest
>
> John Fox's original post is at
> http://tolstoy.newcastle.edu.au/R/devel/05/06/1414.html
>
> The changed files factanal.R and factanal.Rd are attached. If there is
> anything else I can do to help these changes make it into R, please let
> me know.
>
> Thanks and best regards,
>
> Uli
>
> --
> Ulrich Keller
> Université du Luxembourg
> EMACS research unit
> B.P. 2
> L-7201 Walferdange
> Luxembourg
> Mail [EMAIL PROTECTED]
> Phone +352 46 66 44 9 278
>
> --=-hiYzUeWcRJ/+kx41aPIZ
> Content-Disposition: attachment; filename="factanal.R"
> Content-Type: text/plain; name="factanal.R"; charset="utf-8"
> Content-Transfer-Encoding: 7bit
>
> # File src/library/stats/R/factanal.R
> # Part of the R package, http://www.R-project.org
> #
> # This program is free software; you can redistribute it and/or modify
> # it under the terms of the GNU General Public License as published by
> # the Free Software Foundation; either version 2 of the License, or
> # (at your option) any later version.
> #
> # This program is distributed in the hope that it will be useful,
> # but WITHOUT ANY WARRANTY; without even the implied warranty of
> # MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> # GNU General Public License for more details.
> #
> # A copy of the GNU General Public License is available at
> # http://www.r-project.org/Licenses/
>
> ## Hmm, MM thinks diag(.) needs checking { diag(vec) when length(vec)==1
!}
> ## However, MM does not understand that factor analysis
> ## is a *multi*variate technique!
> factanal <-
> function (x, factors, data = NULL, covmat = NULL, n.obs = NA,
> subset, na.action, start = NULL,
> scores = c("none", "regression", "Bartlett"),
> rotation = "varimax",
> control = NULL, ...)
> {
> sortLoadings <- function(Lambda)
> {
> cn <- colnames(Lambda)
> Phi <- attr(Lambda, "covariance")
> ssq <- apply(Lambda, 2, function(x) -sum(x^2))
> Lambda <- Lambda[, order(ssq), drop = FALSE]
> colnames(Lambda) <- cn
> neg <- colSums(Lambda) < 0
> Lambda[, neg] <- -Lambda[, neg]
> if(!is.null(Phi)) {
> unit <- ifelse(neg, -1, 1)
> attr(Lambda, "covariance") <-
> unit %*% Phi[order(ssq), order(ssq)] %*% unit
> }
> Lambda
> }
> cl <- match.call()
> na.act <- NULL
> if (is.list(covmat)) {
> if (any(is.na(match(c("cov", "n.obs"), names(covmat)
> stop("'covmat' is not a valid covariance list")
> cv <- covmat$cov
> n.obs <- covmat$n.obs
> have.x <- FALSE
> }
> else if (is.matrix(covmat)) {
> cv <- covmat
> have.x <- FALSE
> }
> else if (is.null(covmat)) {
> if(missing(x)) stop("neither 'x' nor 'covmat' supplied")
> have.x <- TRUE
> if(inherits(x, "formula")) {
> ## this is not a `standard' model-fitting function,
> ## so no need to consider contrasts or levels
> mt <- terms(x, data = data)
> if(attr(mt, "response") > 0)
> stop("response not allowed in formula")
> attr(mt, "intercept") <- 0
> mf <-
Re: [Rd] 'xtfrm' performance (influences 'order' performance) in R devel
In fact it all comes back to 'rank', which uses 'order(x[!nas])'
internally. Surprisingly one does not get an infinite recursion: rank ->
order -> xtfrm -> rank -> ...
This is obviously only one of possible outcomes, yet it seems to be
happening. Previous implementation of order did not have a reference to
xtfrm and thus would not cause this infinite loop
Dr Oleg Sklyar
Research Technologist
AHL / Man Investments Ltd
+44 (0)20 7144 3107
[EMAIL PROTECTED]
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Sklyar,
> Oleg (London)
> Sent: 09 September 2008 15:49
> To: John Chambers
> Cc: R-devel@r-project.org
> Subject: Re: [Rd] 'xtfrm' performance (influences 'order'
> performance) in R devel
>
> Ha, defined xtfrm for TimeDate, works instantly (xtfrm is already a
> method). However, it won't be taken up by order as it is not in the
> imported namespace, so order falls back to xtfrm.default.
>
> Moreover, defining order (which is not a method unfortunately, *any
> chance of changing this*?):
>
> setGeneric("order")
> setMethod("order", "TimeDate",
> function (..., na.last = TRUE, decreasing = FALSE)
> order(list(...)[EMAIL PROTECTED],na.last=na.last,
> decreasing=decreasing))
>
> does not help either as it won't be taken up, order still calls the
> default one, what am I doing wrong?
>
>
>
> Dr Oleg Sklyar
> Research Technologist
> AHL / Man Investments Ltd
> +44 (0)20 7144 3107
> [EMAIL PROTECTED]
>
> > -Original Message-
> > From: John Chambers [mailto:[EMAIL PROTECTED]
> > Sent: 09 September 2008 15:11
> > To: Sklyar, Oleg (London)
> > Cc: R-devel@r-project.org
> > Subject: Re: [Rd] 'xtfrm' performance (influences 'order'
> > performance) in R devel
> >
> > No definitive answers, but here are a few observations.
> >
> > In the call to order() code, I notice that you have dropped
> > into the branch
> > if (any(unlist(lapply(z, is.object
> > where the alternative in your case would seem to have been
> > going directly to the internal code.
> >
> > You can consider a method for xtfrm(), which would help but
> > won't get you completely back to a trivial computation.
> > Alternatively, order() should be eligible for the new
> > mechanism of defining methods for "...".
> >
> > (Individual existing methods may not be the issue, and one
> > can't infer anything definite from the evidence given, but a
> > plausible culprit is the "[" method. Because [] expressions
> > appear so often, it's always chancy to define a nontrivial
> > method for this function.)
> >
> > John
> >
> > Sklyar, Oleg (London) wrote:
> >
> > Hello everybody,
> >
> > it looks like the presense of some (do know know which)
> > S4 methods for a
> > given S4 class degrades the performance of xtfrm (used
> > in 'order' in new
> > R-devel) by a factor of millions. This is for classes
> > that ARE derived
> > from numeric directly and thus should be quite trivial
> > to convert to
> > numeric.
> >
> > Consider the following example:
> >
> > setClass("TimeDateBase",
> > representation("numeric", mode="character"),
> > prototype(mode="posix")
> > )
> > setClass("TimeDate",
> > representation("TimeDateBase", tzone="character"),
> > prototype(tzone="London")
> > )
> > x = new("TimeDate", 1220966224 + runif(1e5))
> >
> > system.time({ z = order(x) })
> > ## > system.time({ z = order(x) })
> > ## user system elapsed
> > ## 0.048 0.000 0.048
> >
> > getClass("TimeDate")
> > ## Class "TimeDate"
> >
> > ## Slots:
> >
> > ## Name: .Data tzone mode
> > ## Class: numeric character character
> >
> > ## Extends:
> > ## Class "TimeDateBase", directly
> > ## Class "numeric", by class "TimeDateBase", distance 2
> > ## Class "vector", by class "TimeDateBase", distance 3
> >
> >
> > Now, if I load a library that not only defines these
> > same classes, but
> > also a bunch of methods for those, then I have the
> > following result:
> >
> > library(AHLCalendar)
> > x = now() + runif(1e5) ## just random times in POSIXct format
> > x[1:5]
> > ## TimeDate [posix] object in 'Europe/London' of length 5:
> > ## [1] "2008-09-09 14:19:35.218" "2008-09-09 14:19:35.672"
> > ## [3] "2008-09-09 14:19:35.515" "2008-09-09 14:19:35.721"
> > ## [5] "2008-09-09 14:19:35.657"
> >
> >
> >
> > system.time({ z = order(x) })
> >
> >
> >
> >
> > Enter a frame number, or 0 to exit
> >
> > 1: system.time({
> > 2: order(x)
> > 3: lapply(z, function(x) if (is.object(x)) xtfrm(x) else x)
> > 4: FUN(X[[1]], ...)
> > 5: xtfrm(x)
> > 6: xtfrm.default(x)
> > 7: as.vector(rank(x, ties.method = "
Re: [Rd] 'xtfrm' performance (influences 'order' performance) in R devel
Sklyar, Oleg (London) wrote:
> Ha, defined xtfrm for TimeDate, works instantly (xtfrm is already a
> method). However, it won't be taken up by order as it is not in the
> imported namespace, so order falls back to xtfrm.default.
>
By "method" you mean "generic"? xtfrm is an S3 generic. I'm not clear
what happens if you define an S3 method for it. Yes, there is a problem
defining an S4 generic & it would be good to deal with that.
Nontrivial, however.
> Moreover, defining order (which is not a method unfortunately, *any
> chance of changing this*?):
>
> setGeneric("order")
> setMethod("order", "TimeDate",
> function (..., na.last = TRUE, decreasing = FALSE)
> order(list(...)[EMAIL PROTECTED],na.last=na.last,
> decreasing=decreasing))
>
> does not help either as it won't be taken up, order still calls the
> default one, what am I doing wrong?
>
I'm skeptical that this is true. I did a simple example:
> setClass("foo", contains = "numeric", representation(flag = "logical"))
[1] "foo"
> xx = new("foo", rnorm(5))
> setGeneric("order", sig = "...")
Creating a generic for "order" in package ".GlobalEnv"
(the supplied definition differs from and overrides the implicit
generic in package "base": Signatures differ: (...), (na.last, decreasing))
[1] "order"
> setMethod("order", "foo", function (..., na.last = TRUE, decreasing =
FALSE){message("Method called"); order([EMAIL PROTECTED])})
[1] "order"
> order(xx)
Method called
[1] 2 4 3 1 5
You do need to be calling order() directly from one of your functions,
and have it in your namespace, if your package has one.
>
>
> Dr Oleg Sklyar
> Research Technologist
> AHL / Man Investments Ltd
> +44 (0)20 7144 3107
> [EMAIL PROTECTED]
>
>
>> -Original Message-
>> From: John Chambers [mailto:[EMAIL PROTECTED]
>> Sent: 09 September 2008 15:11
>> To: Sklyar, Oleg (London)
>> Cc: R-devel@r-project.org
>> Subject: Re: [Rd] 'xtfrm' performance (influences 'order'
>> performance) in R devel
>>
>> No definitive answers, but here are a few observations.
>>
>> In the call to order() code, I notice that you have dropped
>> into the branch
>> if (any(unlist(lapply(z, is.object
>> where the alternative in your case would seem to have been
>> going directly to the internal code.
>>
>> You can consider a method for xtfrm(), which would help but
>> won't get you completely back to a trivial computation.
>> Alternatively, order() should be eligible for the new
>> mechanism of defining methods for "...".
>>
>> (Individual existing methods may not be the issue, and one
>> can't infer anything definite from the evidence given, but a
>> plausible culprit is the "[" method. Because [] expressions
>> appear so often, it's always chancy to define a nontrivial
>> method for this function.)
>>
>> John
>>
>> Sklyar, Oleg (London) wrote:
>>
>> Hello everybody,
>>
>> it looks like the presense of some (do know know which)
>> S4 methods for a
>> given S4 class degrades the performance of xtfrm (used
>> in 'order' in new
>> R-devel) by a factor of millions. This is for classes
>> that ARE derived
>> from numeric directly and thus should be quite trivial
>> to convert to
>> numeric.
>>
>> Consider the following example:
>>
>> setClass("TimeDateBase",
>> representation("numeric", mode="character"),
>> prototype(mode="posix")
>> )
>> setClass("TimeDate",
>> representation("TimeDateBase", tzone="character"),
>> prototype(tzone="London")
>> )
>> x = new("TimeDate", 1220966224 + runif(1e5))
>>
>> system.time({ z = order(x) })
>> ## > system.time({ z = order(x) })
>> ## user system elapsed
>> ## 0.048 0.000 0.048
>>
>> getClass("TimeDate")
>> ## Class "TimeDate"
>>
>> ## Slots:
>>
>> ## Name: .Data tzone mode
>> ## Class: numeric character character
>>
>> ## Extends:
>> ## Class "TimeDateBase", directly
>> ## Class "numeric", by class "TimeDateBase", distance 2
>> ## Class "vector", by class "TimeDateBase", distance 3
>>
>>
>> Now, if I load a library that not only defines these
>> same classes, but
>> also a bunch of methods for those, then I have the
>> following result:
>>
>> library(AHLCalendar)
>> x = now() + runif(1e5) ## just random times in POSIXct format
>> x[1:5]
>> ## TimeDate [posix] object in 'Europe/London' of length 5:
>> ## [1] "2008-09-09 14:19:35.218" "2008-09-09 14:19:35.672"
>> ## [3] "2008-09-09 14:19:35.515" "2008-09-09 14:19:35.721"
>> ## [5] "2008-09-09 14:19:35.657"
>>
>>
>>
>> system.time({ z = order(x) })
>>
>>
>>
>>
>> Enter a frame number, or 0 to exit
>>
>> 1: system.time({
>> 2: o
Re: [Rd] 'xtfrm' performance (influences 'order' performance) in R devel
Aha, it works if I do
setGeneric("order", signature="...")
However the problem with that is that it generates a warning which I
cannot suppress on install:
Creating a generic for "order" in package "AHLCalendar"
(the supplied definition differs from and overrides the implicit
generic in package "base": Signatures differ: (...), (na.last,
decreasing))
and it generates a warning about masking order from base on load:
AHLCalendar [0.2.42] (9 Sep 2008). ?AHLCalendar or
vignette('AHLCalendar') to get started
Attaching package: 'AHLCalendar'
The following object(s) are masked from package:base :
order
The package exports (excerpt):
exportPattern("^[^\\.]")
exportMethods(order)
The reason for these messages is that the signature is different and I
particularly dislike the masking thing (as I cannot predict if it leads
to other problems somewhere). As I understand the current dotsMethods
does not allow mixing dots and other types, so I cannot really define a
matching signature. Is that right? Is there a way around it?
As for the rest, yes, I meant generic and it works nicely for xtfrm. But
as I wrote later, the problem is in 'rank' and rank is not generic so
defining a method would not help in calling a different implementation.
Thanks,
Oleg
Dr Oleg Sklyar
Research Technologist
AHL / Man Investments Ltd
+44 (0)20 7144 3107
[EMAIL PROTECTED]
> -Original Message-
> From: John Chambers [mailto:[EMAIL PROTECTED]
> Sent: 09 September 2008 16:42
> To: Sklyar, Oleg (London)
> Cc: R-devel@r-project.org
> Subject: Re: [Rd] 'xtfrm' performance (influences 'order'
> performance) in R devel
>
> Sklyar, Oleg (London) wrote:
>
> Ha, defined xtfrm for TimeDate, works instantly (xtfrm
> is already a
> method). However, it won't be taken up by order as it
> is not in the
> imported namespace, so order falls back to xtfrm.default.
>
>
> By "method" you mean "generic"? xtfrm is an S3 generic. I'm
> not clear what happens if you define an S3 method for it.
> Yes, there is a problem defining an S4 generic & it would be
> good to deal with that. Nontrivial, however.
>
>
>
> Moreover, defining order (which is not a method
> unfortunately, *any
> chance of changing this*?):
>
> setGeneric("order")
> setMethod("order", "TimeDate",
> function (..., na.last = TRUE, decreasing = FALSE)
> order(list(...)[EMAIL PROTECTED],na.last=na.last,
> decreasing=decreasing))
>
> does not help either as it won't be taken up, order
> still calls the
> default one, what am I doing wrong?
>
>
> I'm skeptical that this is true. I did a simple example:
>
> > setClass("foo", contains = "numeric", representation(flag =
> "logical"))
> [1] "foo"
> > xx = new("foo", rnorm(5))
> > setGeneric("order", sig = "...")
> Creating a generic for "order" in package ".GlobalEnv"
> (the supplied definition differs from and overrides the
> implicit generic in package "base": Signatures differ:
> (...), (na.last, decreasing))
> [1] "order"
> > setMethod("order", "foo", function (..., na.last = TRUE,
> decreasing = FALSE){message("Method called"); order([EMAIL PROTECTED])})
> [1] "order"
> > order(xx)
> Method called
> [1] 2 4 3 1 5
>
> You do need to be calling order() directly from one of your
> functions, and have it in your namespace, if your package has one.
>
>
>
>
>
> Dr Oleg Sklyar
> Research Technologist
> AHL / Man Investments Ltd
> +44 (0)20 7144 3107
> [EMAIL PROTECTED]
>
>
>
> -Original Message-
> From: John Chambers [mailto:[EMAIL PROTECTED]
> Sent: 09 September 2008 15:11
> To: Sklyar, Oleg (London)
> Cc: R-devel@r-project.org
> Subject: Re: [Rd] 'xtfrm' performance
> (influences 'order'
> performance) in R devel
>
> No definitive answers, but here are a few observations.
>
> In the call to order() code, I notice that you
> have dropped
> into the branch
> if (any(unlist(lapply(z, is.object
> where the alternative in your case would seem
> to have been
> going directly to the internal code.
>
> You can consider a method for xtfrm(), which
> would help but
> won't get you completely back to a trivial
> computation.
> Alternatively, order() should be eligible for the new
> mechanism of defining methods for "...".
>
> (Individual existing methods may not be the
> issue, and one
> can't infer anything definite from the evidence
> given, but a
> plausible culprit is the "[" method. Because
> [] expressions
>
[Rd] Defining an alias for a generic function and callNextMethod() strange behaviour
Hi,
My package contains the following foo() generic and methods (simplified
version):
setGeneric("foo", signature="x", function(x, y=NA) standardGeneric("foo"))
setMethod("foo", "ANY", function(x, y=NA) list(x, y))
setMethod("foo", "character", function(x, y=NA) unlist(callNextMethod()))
> foo(5)
[[1]]
[1] 5
[[2]]
[1] NA
> foo("a")
[1] "a" NA
And I want to define a temporary alias for foo() for backward
compatibility with some existing code:
oldfoo <- function(...) { .Deprecated("foo"); foo(...) }
> oldfoo(5)
[[1]]
[1] 5
[[2]]
[1] NA
Warning message:
'oldfoo' is deprecated.
Use 'foo' instead.
See help("Deprecated")
> oldfoo("a")
Error in .nextMethod() : argument "x" is missing, with no default
In addition: Warning message:
'oldfoo' is deprecated.
Use 'foo' instead.
See help("Deprecated")
Why isn't this working?
One way to make this work is to specify the arguments in the call
to callNextMethod(), or in the definition of the oldfoo alias.
But wouldn't that be nice to be able to just use
fooalias <- function(...) foo(...) for aliasing?
Thanks!
H.
R version 2.7.0 (2008-04-22)
i686-pc-linux-gnu
locale:
LC_CTYPE=en_CA.UTF-8;LC_NUMERIC=C;LC_TIME=en_CA.UTF-8;LC_COLLATE=en_CA.UTF-8;LC_MONETARY=C;LC_MESSAGES=en_CA.UTF-8;LC_PAPER=en_CA.UTF-8;LC_NAME=C;LC_ADDRESS=C;LC_TELEPHONE=C;LC_MEASUREMENT=en_CA.UTF-8;LC_IDENTIFICATION=C
attached base packages:
[1] stats graphics grDevices utils datasets methods base
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] should system.file(package="no such pkg", "no such file") warn or abort?
Currently
system.file(package="no such pkg","no","such","file")
silently returns the empty string, "", if said file doesn't
exist. This forces the caller to check for "" or risk getting
a mysterious error message from a function requiring a file
name. E.g.,
> read.dcf(system.file(package="no such pkg","DESCRIPTION"))
Error in gzfile(file, "r") : cannot open the connection
In addition: Warning message:
In gzfile(file, "r") :
cannot open compressed file '', probable reason 'No such file or directory'
> readLines(system.file(package="no such pkg","no","such","file"))
character(0)
Warning message:
In file(con, "r") :
file("") only supports open = "w+" and open = "w+b": using the former
> read.table(system.file(package="no such pkg","examples","data.txt"))
Error in read.table(system.file(package = "no such pkg", "examples",
"data.txt")) :
no lines available in input
In addition: Warning message:
In file(file, "r") :
file("") only supports open = "w+" and open = "w+b": using the former
I think it would help if system.file(), by default, threw an error
in this case. It could have an argument to suppress the error
if the caller desires. I suppose it could just have a warning.
I've attached a prototype, with the new argument missingFileOK=FALSE.
(I don't like the name, but didn't take the time to come up with
something better.)
> read.table(system.file(package="no such pkg","examples","data.txt"))
Error in system.file(package = "no such pkg", "examples", "data.txt") :
Cannot find package "no such pkg"
> read.table(system.file(package="base", "no", "such", "file"))
Error in system.file(package = "base", "no", "such", "file") :
Cannot find file "no/such/file" in package "base"
> system.file(package="no such pkg","examples","data.txt",
missingFileOK=TRUE)
[1] ""
Is this sort of thing desirable? It would require changes to
code that calls system.file() and checks for its output being "",
but it would make code that doesn't make the check work better.
`system.file` <-
function (..., package = "base", lib.loc = NULL, missingFileOK = FALSE)
{
if (nargs() == 0)
return(file.path(.Library, "base"))
if (length(package) != 1)
stop("'package' must be of length 1")
packagePath <- .find.package(package, lib.loc, quiet = TRUE)
if (length(packagePath) == 0) {
if (missingFileOK)
return("")
else
stop("Cannot find package ", dQuote(package))
}
FILES <- file.path(packagePath, ...)
present <- file.exists(FILES)
if (any(present))
FILES[present]
else if (missingFileOK)
""
else stop("Cannot find file ", dQuote(file.path(...)), " in package ",
dQuote(package))
}
The diffs are
--- system.file.R~ 2008-09-09 13:47:06.608527000 -0700
+++ system.file.R 2008-09-09 11:46:41.509481000 -0700
@@ -1,16 +1,23 @@
`system.file` <-
-function (..., package = "base", lib.loc = NULL)
+function (..., package = "base", lib.loc = NULL, missingFileOK = FALSE)
{
if (nargs() == 0)
return(file.path(.Library, "base"))
if (length(package) != 1)
stop("'package' must be of length 1")
packagePath <- .find.package(package, lib.loc, quiet = TRUE)
-if (length(packagePath) == 0)
-return("")
+if (length(packagePath) == 0) {
+if (missingFileOK)
+return("")
+else
+stop("Cannot find package ", dQuote(package))
+}
FILES <- file.path(packagePath, ...)
present <- file.exists(FILES)
if (any(present))
FILES[present]
-else ""
+else if (missingFileOK)
+""
+else stop("Cannot find file ", dQuote(file.path(...)), " in package ",
dQuote(package))
}
Bill Dunlap
TIBCO Spotfire
bill at insightful dot com (for a while)
"All statements in this message represent the opinions of the author and do
not necessarily reflect TIBCO Software Inc. policy or position."
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
