[Rd] NAMESPACE choices for exporting S4 methods
We are building a package, and want to create S4 methods for both head and mean for our own BigMatrix class. Following the recommendation in "Writing R Extensions" we use exportMethods instead of export in NAMESPACE (this is described as being "clearer"). This works for head, but not for mean. Obviously we importFrom(utils, head), but don't need to do this for mean, which is imported automatically from base. If we export(mean) rather than exportMethods(mean), it works as intended. A similar problem arises for a new generic function and an associated method, colmean, where the use of exportMethods(colmean) fails, but export(colmean) succeeds. We can build and use the package by using export instead of exportMethods, but we suspect that we're missing something that might be important to understand. Any hints or links to something we missed would be appreciated. Thanks, Jay Emerson Michael Kane -- John W. Emerson (Jay) Assistant Professor of Statistics Director of Graduate Studies Department of Statistics Yale University http://www.stat.yale.edu/~jay [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] NAMESPACE choices for exporting S4 methods
On Sat, 8 Dec 2007, Jay Emerson wrote: > We are building a package, and want to create S4 methods for both head and > mean for our own BigMatrix class. Following the recommendation in "Writing > R Extensions" we use exportMethods instead of export in NAMESPACE (this is > described as being "clearer"). This works for head, but not for mean. > Obviously we importFrom(utils, head), but don't need to do this for mean, > which is imported automatically from base. And what is the error message? > If we export(mean) rather than exportMethods(mean), it works as intended. > A similar problem arises for a new generic function and an associated > method, colmean, where the use of exportMethods(colmean) fails, but > export(colmean) succeeds. > > We can build and use the package by using export instead of exportMethods, > but we suspect that we're missing something that might be important to > understand. > > Any hints or links to something we missed would be appreciated. I know there are problems if you define a generic and no methods in a package (that is what stats4 does for AIC), but it doesn't sound as if that is what you are doing. (Since the introduction of implicit generics - which may well apply to your mean() - it is possible to define a generic in a package without any methods stored there, not even a default method.) I saw nothing in your description that is different from several other pacakges. Without either the error messages or an example, we are reduced to guessing. Can you make a minimal version available to us to look at? -- 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] suggested modification to the 'mle' documentation?
On Fri, 7 Dec 2007, Ben Bolker wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Luke Tierney wrote:
>> On Fri, 7 Dec 2007, Duncan Murdoch wrote:
>>
>>
>>
>> For working at the general likelihood I think is is better to
>> encourage the approach of definign likelihood constructor functions.
>> The problem with using f, data is that you need to mathc the names
>> used in f and in data, so either you have to explicitly write out f
>> with the names you have in data or you have to modify data to use the
>> names f likes -- in the running example think
>>
>> f <- function(lambda) -sum(dpois(x, lambda, log=T))
>> d <- data.frame(y=rpois(1, 12.34))
>>
>> somebody has to connext up the x in f with the y in d. With a negative
>> log likelihood constructor defines, for example, as
>>
>> makePoisonNegLogLikelihood <- function(x)
>> function(lambda) -sum(dpois(x, lambda, log=T))
>>
>> this happens naturally with
>>
>> makePoisonNegLogLikelihood(d$y)
>>
>>
>
> I hate to sound like a jerk, but I do hope that in the end we come
> up with a solution that will still be accessible to people who don't
> quite have the concept of writing functions to produce functions.
Any programming language has some idioms and conventions that are
worth lerning if you are going to make most effective use of the
language. R is no exception. One can use R as interactive C but the
results aren't likely to be too satisfactory. Three ideas worth
learning in R (not an exclusive list) are how to use vectorized
arithmetic, how to use the apply family of functions, and how to take
advantage of lexical scope. None of hese is hard to learn, and basic
lexical scope may be the easiest of the three, and the small
investment will pay off.
Best,
luke
> I
> feel it is "natural" for people who have multiple data sets to have the
> variables named similarly in different data sets. All of the
> constructor stuff is still accessible to anyone who wants to use the
> function that way ... is there any way to do a cheesy default
> constructor that is just equivalent to taking the likelihood function
> and arranging for it to be evaluated in an environment containing
> the data? That way if "nllmaker" below were just a formula
> or a log-likelihood function it could still work ...
>
> [snip]
>> Both (simple) bootstrapping and (simple leave-one-out) crossvalidation
>> require a data structure with a notion of cases, which is much more
>> restrictive than the conext in which mle can be used. A more ngeneric
>> aproach to bootstrapping that might fit closer to the level of
>> generality of mle might be parameterized in terms of a negative log
>> likelihood constructor, a starting value constructor, and a resampling
>> function, with a single iteration implemented soemthing like
>>
>> mleboot1 <- function(nllmaker, start, esample) {
>> newdata <- resample()
>> newstart <- do.call(start, newdata)
>> nllfun <- do.call(nllmaker, newdata)
>> mle(fnllfun, start = newstart)
>> }
>>
>> This would leave decisions on the resampling method and data structure
>> up to the user. Somehing similar could be done with K-fold CV.
>>
>> luke
>>
>>
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.6 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iD8DBQFHWcS1c5UpGjwzenMRAig2AJ9iTzhI1p8tBb7Q15jgT4nA+Zds+gCgggc2
> sI2que28Hl1M5cVGa+anEL0=
> =hCiS
> -END PGP SIGNATURE-
>
--
Luke Tierney
Chair, Statistics and Actuarial Science
Ralph E. Wareham Professor of Mathematical Sciences
University of Iowa Phone: 319-335-3386
Department of Statistics andFax: 319-335-3017
Actuarial Science
241 Schaeffer Hall email: [EMAIL PROTECTED]
Iowa City, IA 52242 WWW: http://www.stat.uiowa.edu
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] suggested modification to the 'mle' documentation?
On Sat, 8 Dec 2007, Peter Dalgaard wrote:
> Luke Tierney wrote:
>
> [misc snippage]
>>>
>>> But I'd prefer to avoid the necessity for users to manipulate the
>>> environment of a function. I think the pattern
>>>
>>> model( f, data=d )
>>
>> For working at the general likelihood I think is is better to
>> encourage the approach of definign likelihood constructor functions.
>> The problem with using f, data is that you need to mathc the names
>> used in f and in data, so either you have to explicitly write out f
>> with the names you have in data or you have to modify data to use the
>> names f likes -- in the running example think
>>
>> f <- function(lambda) -sum(dpois(x, lambda, log=T))
>> d <- data.frame(y=rpois(1, 12.34))
>>
>> somebody has to connext up the x in f with the y in d.
> [more snippage]
>
> That's not really worse than having to match the names in a model formula to
> the names of the data frame in lm(), is it?
Yes and no.
If the likelihood is simple engough to include in line, is in
d <- data.frame(y=rpois(100,12.34))
mle(function(lambda) -sum(dpois(d$y, lambda, log = TRUE)),
start = list(lambda=10))
or neaarly in line, eg in a with or local construct, like
with(d, {
f <- function(lambda) -sum(dpois(y, lambda, log = TRUE))
mle(f, start = list(lambda=10))
})
or
local({
y <- d$y
f <- function(lambda) -sum(dpois(y, lambda, log = TRUE))
mle(f, start = list(lambda=10))
})
then I think it is essentially the same. But if the function is
complex enough that you will want to define and debug it separately
then you will probably want to be able to reuse your code directly,
not with copy-paste-edit. At that point things are different.
In a sense this difference also exists with model formulas as well. We
usually write formular in line, rather than something like
f <- y ~ x
lm(f)
With simple formulalas that is reasonable. But it would be nice to be
able to abstract out common patterns of more complex fomulas for
simple reuse. A simple-minded example might be to be able to define a
splitPlot formula operator so one can write
yield ~ splitPlot(whole = fertilizer, sub = variety)
This sort of thing would become more useful in more complicated
multi-level models. I could be wrong but I don't think BUGS has the
ability to abstract out submodel patterns in this way. Don't know if
any of the other multi-level modeling systems provide this. Might be
worth looking into; it's not unrelated to the issues you raise below.
luke
>
> The thing that I'm looking for in these matters is a structure which allows
> us to operate on likelihood functions in a rational way, e.g. reparametrize
> them, join multiple likelihoods with some parameters in common, or integrate
> them. The join operation is illustrative: You can easily do
> negljoint <- function(alpha, beta, gamma, delta)
> negl1(alpha, beta, gamma) + negl2(beta, gamma, delta)
>
> and with a bit of diligence, this could be the result of Join(negl1, negl2).
> But if the convention is that likelihods have their their data as an
> argument, you also need to also automatically define a data argument fot
> negljoint, (presumably a list of two) and organize that the calls to negl1
> and negl2 contains the appropriate subdata. It is the sort of thing that
> might be doable, but you'd rather do without.
>
> -pd
>
>
--
Luke Tierney
Chair, Statistics and Actuarial Science
Ralph E. Wareham Professor of Mathematical Sciences
University of Iowa Phone: 319-335-3386
Department of Statistics andFax: 319-335-3017
Actuarial Science
241 Schaeffer Hall email: [EMAIL PROTECTED]
Iowa City, IA 52242 WWW: http://www.stat.uiowa.edu
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] NAMESPACE choices for exporting S4 methods
At Brian Ripley's request, I started putting together a minimal package to
illustrate the problem (see below for my original post). As usually
happens, I have stumbled on the problem: our zzz.R file contained the
command:
.noGenerics <- TRUE
which we probably copied blindly from some example. After removing this I
was able to use exportMethods(mean) instead of export(mean), as
recommended. In case others find this helpful, I copy the following, which
I found in the help file for library {base}.
"
Formal methods
library takes some further actions when package methods is attached (as it
is by default). Packages may define formal generic functions as well as
re-defining functions in other packages (notably base) to be generic, and
this information is cached whenever such a package is loaded after
methodsand re-defined functions are excluded from the list of
conflicts. The check
requires looking for a pattern of objects; the pattern search may be avoided
by defining an object .noGenerics (with any value) in the package.
Naturally, if the package *does* have any such methods, this will prevent
them from being used.
"
Regards,
Jay
On Dec 8, 2007 4:12 PM, Jay Emerson <[EMAIL PROTECTED]> wrote:
> We are building a package, and want to create S4 methods for both head and
> mean for our own BigMatrix class. Following the recommendation in "Writing
> R Extensions" we use exportMethods instead of export in NAMESPACE (this is
> described as being "clearer"). This works for head, but not for mean.
> Obviously we importFrom(utils, head), but don't need to do this for mean,
> which is imported automatically from base.
>
> If we export(mean) rather than exportMethods(mean), it works as intended.
>
> A similar problem arises for a new generic function and an associated
> method, colmean, where the use of exportMethods(colmean) fails, but
> export(colmean) succeeds.
>
> We can build and use the package by using export instead of exportMethods,
> but we suspect that we're missing something that might be important to
> understand.
>
> Any hints or links to something we missed would be appreciated.
>
> Thanks,
>
> Jay Emerson
> Michael Kane
>
>
> --
> John W. Emerson (Jay)
> Assistant Professor of Statistics
> Director of Graduate Studies
> Department of Statistics
> Yale University
> http://www.stat.yale.edu/~jay
>
--
John W. Emerson (Jay)
Assistant Professor of Statistics
Director of Graduate Studies
Department of Statistics
Yale University
http://www.stat.yale.edu/~jay
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] buglet in curve?
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Symptoms: curve with log x axis gets the wrong
x limits (in 2.6.1, I believe introduced in this version).
Credit goes to Mike McCoy for detecting the problem.
Demonstration:
x = 1:5
plot(x,5*exp(-x),xlim=c(0.1,1000),log="x")
xvec = 10^seq(-1,3,length=100)
lines(xvec,5*exp(-xvec))
curve(5*exp(-x),add=TRUE,col=2,lwd=3)
I believe the problem arises from this fix:
o curve() with unspecified 'from', 'to' and 'xlim' now reuses the
previous x limits, and not slightly larger ones.
and I believe the solution is to replace this ...
if (is.null(xlim))
delayedAssign("lims", {
pu <- par("usr")[1:2]
ll <- if (par("xlog"))
10^pu
else pu
if (par("xaxs") == "r")
extendrange(ll, f = -1/27)
else ll
})
with this ...
if (is.null(xlim))
delayedAssign("lims", {
pu <- par("usr")[1:2]
if (par("xaxs") == "r")
pu <- extendrange(pu, f = -1/27)
ll <- if (par("xlog"))
10^pu
else pu
ll
})
i.e., extend pu, not ll ...
cheers
Ben Bolker
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFHW2sWc5UpGjwzenMRApDiAJ9VNtfvdFBbFQvF6Nt5BrgkvcsunACfZFeg
eHBtIBAxrRvj1LpRkT6wdgo=
=ZFiA
-END PGP SIGNATURE-
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] writing S4 documentation
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I am getting horribly snarled trying to write S4 documentation.
What is the best existing reference? I've been looking at
help("Documentation",package="methods") (which is where R-exts
points to). Does http://bioinf.wehi.edu.au/limma/Rdocs.html exist
anywhere, any more?
Ben Bolker
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFHW4GNc5UpGjwzenMRAhVbAJoCtN0kyUmiSVSwW3cjQYQmgQd0qACdGigo
LMMGnNdlodrCETGuIWunTd4=
=JFws
-END PGP SIGNATURE-
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
