Re: [Rd] improved error message when existing implicit S4 generic is not imported?
I think the message is accurate [*]: you do however need to have a clear
understanding of the scoping issues involved, and no message is going to
give you that.
In short, implicit generics are converted (or not) into explicit
functions to be dumped during the dump-for-lazy-loading phase of R CMD
INSTALL: loading the namespace finds whatever function of that name is
in scope at that time, and once there are multiple functions of the same
name around, different ones may be in scope at different times.
To take one recent example from CRAN:
library(VGAM) # fine, as VGAM loads stats4 via Depends:
and in another session
loadNamespace('VGAM')
Error: Functions for exporting methods must have been made generic,
explicitly or implicitly; not true when loading ‘VGAM’ for ‘AIC’, ‘logLik’
since the visible function AIC() when the namespace alone is loaded is
the one in stats, not the one in stats4 which was visible when the
package was dumped for lazy-loading.
I have little idea how one could express all the possibilities for user
error in an error message like this: as the CRAN maintainers have found,
some package authors cannot comprehend even several-paragraph
explanations tailored to their specific errors. But I might have
written something like:
The function 'plot' found when exporting methods from the namespace
'pkgB' is not an S4 generic.
Hopefully such experiences will encourage people to write NAMESPACE
files more carefully, and also to import generics from e.g. stats4 which
was long ago provided for that purpose. (Re another message: stats4
*is* "methodsGenerics" for base packages.)
[*] at least now that it tells you which namespace is involved, unlike
the original version
On 26/02/2012 06:39, Martin Morgan wrote:
pkgA's NAMESPACE has
importFrom(graphics, plot)
exportClasses("A")
exportMethods("plot")
R/foo.R has
setClass("A")
setMethod("plot", "A", function(x, y, ...) {})
During R CMD INSTALL pkgA_1.0.tar.gz we are told
** preparing package for lazy loading
Creating a generic function for 'plot' from package 'graphics' in
package 'pkgA'
** help
No man pages found in package ‘pkgA’
*** installing help indices
** building package indices
** testing if installed package can be loaded
* DONE (pkgA)
pkgB has in its DESCRIPTION
Depends; pkgA
with NAMESPACE
importFrom(graphics, plot)
exportClasses("B")
exportMethods("plot")
R/bar.R has
setClass("B")
setMethod("plot", "B", function(x, y, ...) {})
During R CMD INSTALL pkgB_1.0.tar.gz we are told
** preparing package for lazy loading
** help
i.e., no implicit generic created (because graphics::plot already has an
implicit generic created, when the pkgA dependency was attached?). and also
** testing if installed package can be loaded
Error : Functions for exporting methods must have been made generic,
explicitly or implicitly; not true when loading 'pkgB' for 'plot'
Error: loading failed
Execution halted
ERROR: loading failed
which doesn't seem accurate, rather "'pkgB' does not import S4 implicit
generic for 'plot' created by 'pkgA'"
> sessionInfo()
R Under development (unstable) (2012-02-25 r58492)
Platform: x86_64-unknown-linux-gnu (64-bit)
Martin
--
Brian D. Ripley, rip...@stats.ox.ac.uk
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
[Rd] Identical copy of base function
Hello, Regarding this in R-devel/NEWS/New features : o library(pkg) no longer warns about a conflict with a function from package:base if the function is an identical copy of the base one but with a different environment. Why would one want an identical copy in a different environment? I'm thinking I may be missing out on a trick here. Matthew __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Identical copy of base function
> Matthew Dowle > on Mon, 27 Feb 2012 09:59:43 + writes: > Hello, > Regarding this in R-devel/NEWS/New features : > o 'library(pkg)' no longer warns about a conflict with a > function from 'package:base' if the function is an > identical copy of the base one but with a different > environment. > Why would one want an identical copy in a different > environment? I'm thinking I may be missing out on a trick > here. Yes, you are ;-) The trick is called ``namespace'' : One example which lead me to implement the above: The Matrix package has had an identical copy of 'det' for a while now, but of course in the Matrix namespace. Because of that, the call to determinant() inside det() will correctly dispatch Matrix methods for determinant(), whereas base::det() would not. Martin __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] prior.weights and weights()
Ben Bolker gmail.com> writes:
Bump? (Quoting with "> " removed to make Gmane happy)
I've since realized that it will be harder to use the
built-in $simulate methods in my application than I thought,
but I'm still curious about this issue (and might still be
able to use them with a slight hack-around if simulate()
methods internally used predict(object,type="response",...))
but I'm still curious about this issue.
And I still think I have shown below that $simulate() doesn't work
properly with na.action=na.exclude ...
Ben Bolker
===
I'm wondering whether anyone has any insight into why the 'simulate'
methods for the built-in glm() families (binomial, Poisson, Gamma ...)
extract the prior weights using object$prior.weights rather than
weights(object,"prior") ?
At first I thought this was so that things work correctly when e.g.
subset= and na.action=na.exclude are used. However, the current versions
of the functions don't seem to work particularly well when these options
are used. A Poisson example, along with a modified function that is
na.exclude-safe, is shown below ...
My reason for wanting this is that I'm working on a package that uses
glm-like objects that don't have list-like structure, so can't contain
$prior.weights elements. If weights were accessed using accessors, then
we could use the existing simulate() functions ...
If R-core agreed that this is a shortcoming of the current
implementation, all of the simulate() methods would need to be rewritten
to account for this (as far as I can see there are four, for
binomial/Poisson/Gamma/inverse Gaussian -- the base method in
simulate.lm works OK (although it generates unnecessary random deviates
corresponding to the NA values in the fitted output).
Actually, an even better design (in my opinion) might be to use
predict(object,type="response",...) internally rather than fitted() --
this would, for free, allow the use case
simulate(object,newdata=...)
which would simulate values from the model for a novel set of
predictor variables ... (coincidentally, this would also allow our
package to use the existing framework more easily).
Are there any circumstances under which
predict(object,type="response") is/could be *different* from
fitted(object) for a 'glm' object ... ?
cheers
Ben Bolker
===
d <- data.frame(y=rpois(10,1),x=rep(c(1,NA),5),f=rep(1:2,each=5))
## subset AND NA omission
g <- glm(y~x,data=d,subset=(f==2),family=poisson)
length(fitted(g)) ## 2
length(weights(g)) ## 2
length(g$prior.weights) ## 2
poisson()$simulate(g,1) ## works
## now try na.exclude
g <- glm(y~x,data=d,subset=(f==2),na.action=na.exclude,
family=poisson)
length(fitted(g)) ## 5
length(weights(g)) ## 5
length(g$prior.weights) ## 2
poisson()$simulate(g,1) ## fails
## here's a new, 'safe' version of the Poisson simulate function ...
simnew <- function (object, nsim) {
wts <- weights(object)
if (any(na.omit(wts) != 1))
warning("ignoring prior weights")
ftd <- na.omit(fitted(object))
napredict(na.action(object),
rpois(nsim * length(ftd), ftd))
}
simnew(g,1)
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Identical copy of base function
Doesn't this also mean that if Matrix is loaded first, det() will be calling Matrix::determinant, which could be quite surprising change in behavior from expectation? This seems rather dangerous and 'untrustworthy' to me - unless I am missing some other hidden mechanism involved here. I haven't read the code yet, and I am sure Matrix will "do the right thing", but I have strong reservations about this behavior when applied to the general universe of R and CRAN. Jeff On Mon, Feb 27, 2012 at 6:03 AM, Martin Maechler wrote: >> Matthew Dowle >> on Mon, 27 Feb 2012 09:59:43 + writes: > > > Hello, > > > Regarding this in R-devel/NEWS/New features : > > > o 'library(pkg)' no longer warns about a conflict with a > > function from 'package:base' if the function is an > > identical copy of the base one but with a different > > environment. > > > Why would one want an identical copy in a different > > environment? I'm thinking I may be missing out on a trick > > here. > > Yes, you are ;-) The trick is called ``namespace'' : > > One example which lead me to implement the above: > > The Matrix package has had an identical copy of 'det' for a > while now, but of course in the Matrix namespace. > Because of that, the call to determinant() inside det() will > correctly dispatch Matrix methods for determinant(), whereas > base::det() would not. > > Martin > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel -- Jeffrey Ryan jeffrey.r...@lemnica.com www.lemnica.com www.esotericR.com R/Finance 2012: Applied Finance with R www.RinFinance.com See you in Chicago __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Identical copy of base function
> Jeffrey Ryan
> on Mon, 27 Feb 2012 07:39:32 -0600 writes:
> Doesn't this also mean that if Matrix is loaded first,
> det() will be calling Matrix::determinant, which could be
> quite surprising change in behavior from expectation?
> This seems rather dangerous and 'untrustworthy' to me -
> unless I am missing some other hidden mechanism involved here.
The only change in R-devel is that library() does not warn about
*conflicts* in such a case.
This behavior (and the R code in library()'s checkConflicts())
is completely analogous to
importFrom("base", det)
export(det)
but as you surely know, we can not (yet?) import from base.
So again: No changed behavior of R, just some warnings less in a
case where they are typically inappropriate.
> I haven't read the code yet, and I am sure Matrix will "do
> the right thing", but I have strong reservations about
> this behavior when applied to the general universe of R
> and CRAN.
> Jeff
> On Mon, Feb 27, 2012 at 6:03 AM, Martin Maechler
> wrote:
>>> Matthew Dowle on Mon,
>>> 27 Feb 2012 09:59:43 + writes:
>>
>> > Hello,
>>
>> > Regarding this in R-devel/NEWS/New features :
>>
>> > o 'library(pkg)' no longer warns about a conflict
>> with a > function from 'package:base' if the function
>> is an > identical copy of the base one but with a
>> different > environment.
>>
>> > Why would one want an identical copy in a different
>> > environment? I'm thinking I may be missing out on a
>> trick > here.
>>
>> Yes, you are ;-) The trick is called ``namespace'' :
>>
>> One example which lead me to implement the above:
>>
>> The Matrix package has had an identical copy of 'det' for
>> a while now, but of course in the Matrix namespace.
>> Because of that, the call to determinant() inside det()
>> will correctly dispatch Matrix methods for determinant(),
>> whereas base::det() would not.
>>
>> Martin
>>
>> __
>> R-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
> --
> Jeffrey Ryan jeffrey.r...@lemnica.com
> www.lemnica.com www.esotericR.com
> R/Finance 2012: Applied Finance with R www.RinFinance.com
> See you in Chicago
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Identical copy of base function
On Mon, Feb 27, 2012 at 9:19 AM, Martin Maechler
wrote:
>> Jeffrey Ryan
>> on Mon, 27 Feb 2012 07:39:32 -0600 writes:
>
> > Doesn't this also mean that if Matrix is loaded first,
> > det() will be calling Matrix::determinant, which could be
> > quite surprising change in behavior from expectation?
>
>
> > This seems rather dangerous and 'untrustworthy' to me -
> > unless I am missing some other hidden mechanism involved here.
>
> The only change in R-devel is that library() does not warn about
> *conflicts* in such a case.
Yes, I understand that is only the warning here - but what, aside from
hiding a conflict (which the user may *indeed* care about), does this
accomplish?
To me, a conflict is something to be aware of - hiding it is where I
become concerned.
Without warning, one R script may run differently now depending on
packages loaded, and not just package functions explicitly called by
the script. Without the warning I can envision countless hours
attempting to debug errors - if one is lucky enough to note the change
in behavior.
Behavioral changes can also related to performance. I had seen this
previously with some cbind behavior when the S4 variant from
package:methods overwrote the (much faster) base::cbind by a package
which I will not name (and has since been fixed).
Jeff
> This behavior (and the R code in library()'s checkConflicts())
> is completely analogous to
> importFrom("base", det)
> export(det)
> but as you surely know, we can not (yet?) import from base.
>
> So again: No changed behavior of R, just some warnings less in a
> case where they are typically inappropriate.
>
> > I haven't read the code yet, and I am sure Matrix will "do
> > the right thing", but I have strong reservations about
> > this behavior when applied to the general universe of R
> > and CRAN.
>
> > Jeff
>
> > On Mon, Feb 27, 2012 at 6:03 AM, Martin Maechler
> > wrote:
> >>> Matthew Dowle on Mon,
> >>> 27 Feb 2012 09:59:43 + writes:
> >>
> >> > Hello,
> >>
> >> > Regarding this in R-devel/NEWS/New features :
> >>
> >> > o 'library(pkg)' no longer warns about a conflict
> >> with a > function from 'package:base' if the function
> >> is an > identical copy of the base one but with a
> >> different > environment.
> >>
> >> > Why would one want an identical copy in a different
> >> > environment? I'm thinking I may be missing out on a
> >> trick > here.
> >>
> >> Yes, you are ;-) The trick is called ``namespace'' :
> >>
> >> One example which lead me to implement the above:
> >>
> >> The Matrix package has had an identical copy of 'det' for
> >> a while now, but of course in the Matrix namespace.
> >> Because of that, the call to determinant() inside det()
> >> will correctly dispatch Matrix methods for determinant(),
> >> whereas base::det() would not.
> >>
> >> Martin
> >>
> >> __
> >> R-devel@r-project.org mailing list
> >> https://stat.ethz.ch/mailman/listinfo/r-devel
>
>
>
> > --
> > Jeffrey Ryan jeffrey.r...@lemnica.com
>
> > www.lemnica.com www.esotericR.com
>
> > R/Finance 2012: Applied Finance with R www.RinFinance.com
>
> > See you in Chicago
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
--
Jeffrey Ryan
jeffrey.r...@lemnica.com
www.lemnica.com
www.esotericR.com
R/Finance 2012: Applied Finance with R
www.RinFinance.com
See you in Chicago
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Conflict from saved implicit generics in methods package for rcond, norm, backsolve
This issue ties loosely into other recent S4 topics on this board.
The methods package defines a number of implicit generics for linear
algebra related functions (rcond, norm, backsolve) that, when used,
interfere with base package operations. Here is the cut-and-paste
version of the code the illustrates the problem:
# rcond
x1 <- cbind(1, 1:10)
rcond(x1)
setGeneric("rcond")
rcond(x1)
# norm
example(norm)
setGeneric("norm")
example(norm)
# backsolve
example(backsolve)
setGeneric("backsolve")
example(backsolve)
Here is an example run:
R> # rcond
R> x1 <- cbind(1, 1:10)
R> rcond(x1)
[1] 0.05278005
R> setGeneric("rcond")
Creating a generic function for 'rcond' from 'base' in the global
environment
(from the saved implicit definition)
[1] "rcond"
R> rcond(x1)
Error in match.arg(norm) : argument "norm" is missing, with no default
R>
R> # norm
R> example(norm)
normR> (x1 <- cbind(1,1:10))
[,1] [,2]
[1,]11
[2,]12
[3,]13
[4,]14
[5,]15
[6,]16
[7,]17
[8,]18
[9,]19
[10,]1 10
normR> norm(x1)
[1] 55
normR> norm(x1, "I")
[1] 11
normR> norm(x1, "M")
[1] 10
normR> stopifnot(all.equal(norm(x1, "F"),
norm+ sqrt(sum(x1^2
normR> hilbert <- function(n) { i <- 1:n; 1 / outer(i - 1, i, "+") }
normR> h9 <- hilbert(9)
normR> ## all 4 types of norm:
normR> (nTyp <- eval(formals(base::norm)$type))
[1] "O" "I" "F" "M"
normR> sapply(nTyp, norm, x=h9)
OIFM
2.828968 2.828968 1.755872 1.00
R> setGeneric("norm")
[1] "norm"
R> example(norm)
normR> (x1 <- cbind(1,1:10))
[,1] [,2]
[1,]11
[2,]12
[3,]13
[4,]14
[5,]15
[6,]16
[7,]17
[8,]18
[9,]19
[10,]1 10
normR> norm(x1)
Error in base::norm(x, type, ...) :
argument "type" is missing, with no default
R>
R> # backsolve
R> example(backsolve)
bckslvR> ## upper triangular matrix 'r':
bckslvR> r <- rbind(c(1,2,3),
bckslv+c(0,1,1),
bckslv+c(0,0,2))
bckslvR> ( y <- backsolve(r, x <- c(8,4,2)) ) # -1 3 1
[1] -1 3 1
bckslvR> r %*% y # == x = (8,4,2)
[,1]
[1,]8
[2,]4
[3,]2
bckslvR> backsolve(r, x, transpose = TRUE) # 8 -12 -5
[1] 8 -12 -5
R> setGeneric("backsolve")
[1] "backsolve"
R> example(backsolve)
bckslvR> ## upper triangular matrix 'r':
bckslvR> r <- rbind(c(1,2,3),
bckslv+c(0,1,1),
bckslv+c(0,0,2))
bckslvR> ( y <- backsolve(r, x <- c(8,4,2)) ) # -1 3 1
Error in base::backsolve(r, x, k = k, upper.tri = upper.tri, transpose =
transpose, :
argument "k" is missing, with no default
R> sessionInfo()
R Under development (unstable) (2012-02-25 r58492)
Platform: x86_64-unknown-linux-gnu (64-bit)
locale:
[1] C
attached base packages:
[1] stats graphics grDevices utils datasets methods base
loaded via a namespace (and not attached):
[1] tools_2.15.0
The controversial bit is how to address the issue:
a) patch them in the methods package
b) patch them and move them along with related implicit generics such as
chol2inv from the methods package to the Matrix package
c) remove them along with similar implicit generics from the methods package
Patrick
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Jazzing up the Task Views index page
On Wed, Feb 22, 2012 at 3:34 PM, Joshua Wiley wrote: > Barry, is this a test/example only or would you plan on keeping > something like that on your site even if it is not adopted for cran > task views? If it is not adopted elsewhere and you are willing to > maintain it, I would like to link to it. It's really only a test, partly for fun, partly to try and kick up some of the dust on the R web pages. There's been a few comments about that, for sure. The main R web pages are becoming secondary to other community sites for information on R and packages and so on. I know it is essentially maintained by the developers primarily for the developers (as is R itself) but at some point the users will take over - as they are with the community sites springing up. However, it would be nice if www.r-project.org took you to a lively, engaging web site with twitter feeds and google +1 buttons and latest news postings. And didn't use framesets. There's also the issue of CRAN and its mirrors. Mirror technology is so last century - the way to do these things now is via CDNs - content delivery networks. You do magic redirection via http 302 responses, or metalinks. It enables better logging, better resilience. All it needs is a running instance of MirrorBrain. Or just stick .nyud.net on the end of the URL and have everything magically cached and proxied by the Coral cache network. The inertia to all this is 'well, it works okay at the moment'. But why is 'okay' okay, when 'better' is better? Anyway, how many of you played 'Top Trumps' when you were kids? My Task Views index reminded me of it, so I just spent an hour grabbing some stats and formatting them: http://www.maths.lancs.ac.uk/~rowlings/R/TaskViews/card.html The inaugural Task Views Top Trumps World Championship will be held in Nashville in June... Barry __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
