[Rd] Alternative to eval(cl, parent.frame()) ?
Dear developeRs,
I maintain a package 'pls', which has a main fit function mvr(), and
functions plsr() and pcr() which are meant to take the same arguments as
mvr() and do exactly the same, but have different default values for the
'method' argument. The three functions are all exported from the name
space.
In the 'pre namespace' era, I took inspiration from lm() and implemented
it like this:
plsr <- function(..., method = pls.options()$plsralg) {
cl <- match.call()
cl$method <- match.arg(method, c("kernelpls", "widekernelpls", "simpls",
"oscorespls", "model.frame"))
cl[[1]] <- as.name("mvr")
res <- eval(cl, parent.frame())
...
Recently, Prof. Brian Ripley kindly pointed out that this doesn't work
properly when the 'pls' package in not attached:
> data(yarn, package='pls')
> pls::plsr(density ~ NIR, 6, data = yarn, validation = "CV")
Error in eval(expr, envir, enclos) : could not find function "mvr"
I first believed that
cl[[1]] <- as.name("pls::mvr")
would fix the problem, but that did not help. I have found that the
following seems to work:
plsr <- function(..., method = pls.options()$plsralg) {
cl <- match.call()
cl$method <- match.arg(method, c("kernelpls", "widekernelpls", "simpls",
"oscorespls", "model.frame"))
arguments <- as.list(cl)[-1]
res <- do.call(mvr, arguments, envir = parent.frame())
...
However, if I understand correctly, this will evaluate the arguments
before handing them over to mvr(). Currently, mvr() doesn't need the
unevaluated arguments, but if it were to, this would be a problem.
Is there an 'R best practice' for achieving what I want (several
versions of the same function, with different default value for an
argument)?
--
Regards,
Bjørn-Helge Mevik
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Alternative to eval(cl, parent.frame()) ?
On Jul 13, 2013, at 10:56 , Bjørn-Helge Mevik wrote:
> Dear developeRs,
>
> I maintain a package 'pls', which has a main fit function mvr(), and
> functions plsr() and pcr() which are meant to take the same arguments as
> mvr() and do exactly the same, but have different default values for the
> 'method' argument. The three functions are all exported from the name
> space.
>
> In the 'pre namespace' era, I took inspiration from lm() and implemented
> it like this:
>
> plsr <- function(..., method = pls.options()$plsralg) {
>cl <- match.call()
>cl$method <- match.arg(method, c("kernelpls", "widekernelpls", "simpls",
> "oscorespls", "model.frame"))
>cl[[1]] <- as.name("mvr")
>res <- eval(cl, parent.frame())
>...
>
>
> Recently, Prof. Brian Ripley kindly pointed out that this doesn't work
> properly when the 'pls' package in not attached:
>
>> data(yarn, package='pls')
>> pls::plsr(density ~ NIR, 6, data = yarn, validation = "CV")
>
> Error in eval(expr, envir, enclos) : could not find function "mvr"
>
> I first believed that
>
>cl[[1]] <- as.name("pls::mvr")
>
> would fix the problem, but that did not help. I have found that the
> following seems to work:
>
> plsr <- function(..., method = pls.options()$plsralg) {
>cl <- match.call()
>cl$method <- match.arg(method, c("kernelpls", "widekernelpls", "simpls",
> "oscorespls", "model.frame"))
>arguments <- as.list(cl)[-1]
>res <- do.call(mvr, arguments, envir = parent.frame())
>...
>
> However, if I understand correctly, this will evaluate the arguments
> before handing them over to mvr(). Currently, mvr() doesn't need the
> unevaluated arguments, but if it were to, this would be a problem.
>
> Is there an 'R best practice' for achieving what I want (several
> versions of the same function, with different default value for an
> argument)?
We discussed this recently, and I believe the winner was
cl[[1]] <- quote(pls::mvr)
(notice that :: is an operator, so this is profoundly different from
as.name("pls::mvr"), which is a symbol with two colons inside!)
--
Peter Dalgaard, Professor,
Center for Statistics, Copenhagen Business School
Solbjerg Plads 3, 2000 Frederiksberg, Denmark
Phone: (+45)38153501
Email: pd@cbs.dk Priv: pda...@gmail.com
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Alternative to eval(cl, parent.frame()) ?
peter dalgaard writes:
> We discussed this recently, and I believe the winner was
>
> cl[[1]] <- quote(pls::mvr)
Thank you!
> (notice that :: is an operator, so this is profoundly different from
> as.name("pls::mvr"), which is a symbol with two colons inside!)
Ah. Of course!
--
Regards,
Bjørn-Helge Mevik
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] missing PROTECT() in src/main/arithmetic.c
> From: Herv? Pag?s > at lines 651 & 653 (integer_binary function): > > if (code == DIVOP || code == POWOP) > ans = allocVector(REALSXP, n); > else > ans = allocVector(INTSXP, n); > > There are calls to warningcall() later in the function, which can > trigger garbbage collection. > > Looks like the typical scenario where it seemed pretty safe to not > PROTECT in the original version of the function but became very > unsafe 3 years later when the calls to warningcall() were added to > the function. Note that there is also a problem with a possible warning from myfmod, which in turn is called from R_pow. The call of myfmod from R_pow should probably be replaced by something else, since as it is, the following undesirable behaviour occurs: > (-Inf)^(1e16) [1] Inf Warning message: probable complete loss of accuracy in modulus I think issuing a warning for this is probably not a good idea, but if a warning is issued, it certainly shouldn't be this one. Radford Neal __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] missing PROTECT() in src/main/arithmetic.c
Thanks -- fixed in 63290 (trunk) and 63291 (patched). luke On Fri, 12 Jul 2013, Hervé Pagès wrote: at lines 651 & 653 (integer_binary function): if (code == DIVOP || code == POWOP) ans = allocVector(REALSXP, n); else ans = allocVector(INTSXP, n); There are calls to warningcall() later in the function, which can trigger garbbage collection. Looks like the typical scenario where it seemed pretty safe to not PROTECT in the original version of the function but became very unsafe 3 years later when the calls to warningcall() were added to the function. Cheers, H. -- 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: luke-tier...@uiowa.edu 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] "Proper" way to use a "hidden" function in an R-package?
On 12 July 2013 at 11:42, Gabriel Becker wrote:
| Jonathan,
|
| All exported functions must have documentation entries to pass R CMD check
| without warnings.
|
| Functions within your package do not need another function in your package
| to be exported to call it without :::, but code not in your package (ie
| functions in other packages or user code) do.
|
| If you have reason to believe that a user or function from another package
| will directly call a function, it should be exported, and thus documented.
| If not, you can use them within code in your own package without exporting
| them, using :::, or documenting them.
All true, but what Jonathan _really_ wanted to know is that adding a single
\alias{nameOfThatFunction}
in an .Rd file will also satisfy R CMD check. Some package use a file
undocumented.Rd to regreoup these; I sometimes use the Packagename-package.Rd
file.
Dirk
--
Dirk Eddelbuettel | e...@debian.org | http://dirk.eddelbuettel.com
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] unmapped memory core dump with pure R program?
dear R developers---I am running a pure R program on the stock binary debian (ubuntu) 64-bit linux distribution, 3.0.1. for identification, 20abb3a1d917bce52a10dd40cb47b82b /usr/lib/R/bin/exec/R 58ebc91f143f752610c8dbe22182f3f3 /usr/lib/libR.so my R program loads 5 big matrices (about 1GB each)and rbind's them, all on a 16GB machine. alas, in one particular run, I am getting a mysterious Error in rbind(deparse.level, ...) : 'pairlist' object cannot be coerced to type 'double' so I dropped into the R debugger (option(error=recover)) and tried to do the rbind by hand again to figure out what this error message means in this context. (it works just fine with other combinations.) when I thus am trying to run it again, I am getting a Browse[1]> head(rbind(dm,db)) *** caught segfault *** address 0x10, cause 'memory not mapped' Traceback: 1: rbind(deparse.level, ...) 2: rbind(dm, db) 3: head(rbind(dm, db)) 4: eval(expr, envir, enclos) ... I then created a core dump (where R prompts me), which goes for 82 levels (to _start), so its not an infinite recursion problem, but it does seem to recurse some. I don't have symbols in my R binary, so the location may not be useful, but I thought I would let you guys know. alas (gdb) bt #0 0x7ff956be3857 in ?? () from /usr/lib/R/lib/libR.so #1 0x7ff956be67d3 in Rf_allocVector () from /usr/lib/R/lib/libR.so #2 0x7ff956b90338 in ?? () from /usr/lib/R/lib/libR.so #3 0x7ff956b8fcfa in ?? () from /usr/lib/R/lib/libR.so #4 0x7ff956b90875 in Rf_duplicate () from /usr/lib/R/lib/libR.so #5 0x7ff956b48e98 in ?? () from /usr/lib/R/lib/libR.so #6 0x7ff956bb56da in ?? () from /usr/lib/R/lib/libR.so #7 0x7ff956bba9a8 in Rf_eval () from /usr/lib/R/lib/libR.so #8 0x7ff956bbec39 in Rf_applyClosure () from /usr/lib/R/lib/libR.so #9 0x7ff956b44c38 in ?? () from /usr/lib/R/lib/libR.so #10 0x7ff956be80a0 in ?? () from /usr/lib/R/lib/libR.so #11 0x7ff956bae21a in ?? () from /usr/lib/R/lib/libR.so #12 0x7ff956bba9a8 in Rf_eval () from /usr/lib/R/lib/libR.so #13 0x7ff956bbec39 in Rf_applyClosure () from /usr/lib/R/lib/libR.so its replicable. not sure if this is of any interest...just trying to help. please ignore if uninteresting. regards, /iaw Ivo Welch (ivo.we...@gmail.com) [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
