[Rd] developing a package: increase the number of functions
Dear list, I am trying to develop a package. I used the function package.skeleton to make the directory tree of the package and then build and compiled the package as described (I hope). Now, I would like to increase the number of functions in the package without overwriting the existing package directory tree, so I put these new functions in the directory R of the tree. When I then build and install the package, I can not find the new functions, so apparently they are omitted from the installation. My question is: why does this occur? What should I do to get these new functions also installed? (I am using R 2.4.1) Thanks in advance, Albart Coster __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] developing a package: increase the number of functions
On Mon, 30 Jul 2007, Coster, Albart wrote: > Dear list, > > I am trying to develop a package. I used the function package.skeleton > to make the directory tree of the package and then build and compiled > the package as described (I hope). Now, I would like to increase the > number of functions in the package without overwriting the existing > package directory tree, so I put these new functions in the directory R > of the tree. When I then build and install the package, I can not find > the new functions, so apparently they are omitted from the installation. What file name(s) did you use? See 'Writing R Extensions' for allowed names, and also remember you need to add documentation for those functions. Do you have a NAMESPACE? > My question is: why does this occur? What should I do to get these new > functions also installed? > > (I am using R 2.4.1) Why? R 2.5.1 is current. -- 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] (PR#9811) sequence(c(2, 0, 3)) produces surprising results,
On Fri, 27 Jul 2007, Prof Brian Ripley wrote: > This is as doumented, and I think you could say the same thing of seq(). > BTW, sequence() allows negative inputs, and I don't think you want > sum(input) in that case. help(sequence) says contradictory things about the nvec[i]==0 case: For each element of 'nvec' the sequence 'seq(nvec[i])' is created. ... and nvec: an integer vector each element of which specifies the upper bound ... 0 is not the upper bound of seq(0). In any case, a suitably general multisequence function would probably want vectors of both to's and from's. merge.data.frame() requires a combination of a vectorized sequence function and rep. It uses a .Internal to do the job well. (This is a case where the individual sequences typically have length one or zero.) > .Internal(merge(rep(1:3, c(3,0,5)), rep(1:4, c(2,2,3,2)), T, T)) $xi [1] 1 1 2 2 3 3 4 4 4 5 5 5 6 6 6 7 7 7 8 8 8 $yi [1] 1 2 1 2 1 2 5 6 7 5 6 7 5 6 7 5 6 7 5 6 7 $x.alone integer(0) $y.alone integer(0) sequence and rep produce complementary outputs, except in the nvec[i]==0 case. > rep(1:3, c(5,2,7)) # identifies group [1] 1 1 1 1 1 2 2 3 3 3 3 3 3 3 > sequence(c(5,2,7)) # which in group [1] 1 2 3 4 5 1 2 1 2 3 4 5 6 7 Bill Dunlap Insightful Corporation bill at insightful dot com 360-428-8146 "All statements in this message represent the opinions of the author and do not necessarily reflect Insightful Corporation policy or position." __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] behavior of L-BFGS-B with trivial function triggers bug in stats4::mle
[sent this last night, may have bounced, resending]
With R 2.5.1 ...
"L-BFGS-B" behaves differently from all of the
other optim() methods, which return the value of the function
when they are given a trivial function (i.e., one with no
variable arguments) to optimize. I don't think this
is a "bug" in L-BFGS-B (more like a response to
an undefined condition), but it leads to a bug in stats4::mle --
a spurious error saying that a better fit
has been found during profiling if one tries to profile
a 1-parameter model that was originally fitted with "L-BFGS-B".
I haven't dug quite all the way to the bottom of this
yet, but the attached code will clearly show the problem.
In the version of mle that I've built (which has
gotten some ugly bells and whistles added) I added
a check which would be more or less equivalent
to check if length(start)==0 and then setting
oout <- list(par=start, value=f(start),
hessian = matrix(numeric(0),0,0)
or something along those lines.
Or one could change L-BFGS-B to behave the same
as the other methods.
cheers
Ben Bolker
-
library(stats4)
## using example from ?mle
x <- 0:10
y <- c(26, 17, 13, 12, 20, 5, 9, 8, 5, 4, 8)
ll <- function(ymax=15, xhalf=6)
-sum(stats::dpois(y, lambda=ymax/(1+x/xhalf), log=TRUE))
## fix one parameter to get 1D profile
fit2 <- mle(ll, fixed=list(xhalf=6))
profile(fit2)
## same again with method="L-BFGS-B"
fit3 <- mle(ll, fixed=list(xhalf=6),method="L-BFGS-B")
profile(fit3) ## BUG
ll0 <- function(zzz) {
ymax <- 15
xhalf <- 6
-sum(stats::dpois(y, lambda=ymax/(1+x/xhalf), log=TRUE))
}
## try mle() with all-fixed parameters with various methods ...
methods = eval(formals(optim)$method)
sapply(methods,
function(m) {
-logLik(mle(ll, start=list(ymax=15,xhalf=6),
fixed=list(ymax=15,xhalf=6),method=m))
})
## Nelder-Mead BFGSCG L-BFGS-B SANN
## 3.389441e+01 3.389441e+01 3.389441e+01 5.048277e-270 3.389441e+01
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] behavior of L-BFGS-B with trivial function triggers bug in stats4::mle
With the exception of "L-BFGS-B", all of the
other optim() methods return the value of the function
when they are given a trivial function (i.e., one with no
variable arguments) to optimize. I don't think this
is a "bug" in L-BFGS-B (more like a response to
an undefined condition), but it leads to a bug in stats4::mle --
a spurious error saying that a better fit
has been found during profiling if one tries to profile
a 1-parameter model.
I haven't dug quite all the way to the bottom of this
yet, but the attached code will clearly show the problem.
In the version of mle that I've built (which has
gotten some ugly bells and whistles added) I added
a check which would be more or less equivalent
to check if length(start)==0 and then setting
oout <- list(par=start, value=f(start),
hessian = matrix(numeric(0),0,0)
or something along those lines.
Or one could change L-BFGS-B to behave the same
as the other methods.
cheers
Ben Bolker
-
library(stats4)
## using example from ?mle
x <- 0:10
y <- c(26, 17, 13, 12, 20, 5, 9, 8, 5, 4, 8)
ll <- function(ymax=15, xhalf=6)
-sum(stats::dpois(y, lambda=ymax/(1+x/xhalf), log=TRUE))
## fix one parameter to get 1D profile
fit2 <- mle(ll, fixed=list(xhalf=6))
profile(fit2)
## same again with method="L-BFGS-B"
fit3 <- mle(ll, fixed=list(xhalf=6),method="L-BFGS-B")
profile(fit3)
ll0 <- function(zzz) {
ymax <- 15
xhalf <- 6
-sum(stats::dpois(y, lambda=ymax/(1+x/xhalf), log=TRUE))
}
## try mle() with all-fixed parameters with various methods ...
methods = eval(formals(optim)$method)
sapply(methods,
function(m) {
-logLik(mle(ll, start=list(ymax=15,xhalf=6),
fixed=list(ymax=15,xhalf=6),method=m))
})
## Nelder-Mead BFGSCG L-BFGS-B SANN
## 3.389441e+01 3.389441e+01 3.389441e+01 5.048277e-270 3.389441e+01
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
