similar to: possible bug in formals

Dear maintainers of the parallel package, I ran into an issue with the parallel package in R-3.1.0. The following code prints the message "NULL!" quite a lot. library(parallel) for (n in 1:1000) { p <- mcparallel(sqrt(n)) res <- mccollect(p, wait=FALSE, timeout=1000) mccollect(p) if (is.null(res)) cat(n," NULL!\n") } It does not happen in

Hi, Our department has detected a bug in the implementation of the Kinderman-Ramage generator for normal random variates in version 1.7.0, which can be seen from the below R session. (Consecutive calls for chisq.test(...) always gives p-values very close to 0.) We have already encountered this bug in version 1.6.2 The error is in file R-1.7.0/src/nmath/snorm.c Here is a patch for this file to

Hi, I sometimes play around with extreme parameters for distributions and found that qbeta is not always monotone as the following example shows. I don't know whether this is serious enough to submit a bug report (as this example is near to the limitations of floating point arithmetic). Josef > x <- qbeta((0:100)/100,0.01,5) > x [1] 0.000000e+00 1.253990e-201 1.589622e-171

Hi, As you probably know, there is a problem with the interface for adding uniform random number generators in R (see by article in R News 5/2, November 2005). There exists a mechanism called "user-supplied" that allows users of R to run their own generator in R. However, there is no such mechanism for package writers. Those who want to add their own generators abuse

Hello, after some discussions with Martin Maechler and Josef Leydold (WU Wien), we have felt the need for some package that should allow for an object-orientated approach to distributions. Our small group at Bayreuth now has developed a package "distr" which tries to fill this gap, implementing distributions by means of S4--classes. A mother class "Distribution" is

Hi all, I have R script which during its run require an input like this: choose between one of the grouping factor available : c("Village", "Country") can I automate this part, in other word to pass for example Village when I am running the script. One more thing the script is the TimeSeriesAnalysis {ndvits}. Thanks in advance for any help or suggestion. Regards, Vahe

Hi, i have used S4 classes to implement a unified access to random number generators (package rstream on CRAN). I have used a construct to allow optional arguments: if(!isGeneric("rstream.sample")) setGeneric("rstream.sample", function(stream,...) standardGeneric("rstream.sample")) setMethod("rstream.sample",

Full_Name: Jörg Polzehl Version: 1.8.0 OS: Windows XP Submission from: (NULL) (62.141.176.1) I encountered a problem when playing with the mle library and specifying negative starting values for the parameters. The reason seems to be an incorrect behaviour of function formals: glike<-function(a=1,b=1,c=1) a > formals(glike) $a [1] 1 $b [1] 1 $c [1] 1 > unlist(formals(glike)) a b c

Hi, Thanks for the note. How would explain the following snippet taken from `formals` doc page (the code comment is also from that doc) ? ## formals returns NULL for primitive functions. Use it in combination with ## args for this case. is.primitive(`+`) formals(`+`) formals(args(`+`)) Le sam. 6 oct. 2018 ? 13:42, Rui Barradas <ruipbarradas at sapo.pt> a ?crit :

With 0.63.3, try test <- function(){ fn <- function(a) print("hello") print(is.function(fn)) print(names(formals("fn")))} test() if fn is not quoted in the last line of test, it works properly. test <- function(){ fn <- function() print("hello") formals(fn) <- alist(a=,b=) return(fn)} formals(test()) now try with line 3 of test changed to

Hi, The R input/output after the following paragraph is from a session with version.string R version 2.4.0 Patched (2006-11-23 r39958). The last element, x$c, of x has no value and after the assignment of x to the formals of f, x$c does not become a formal argument of f. The second assignment does the job. It seems that x$c actually becomes the body of f after the first assignment. There is no

Hi, A short code example showing the warning might the only thing needed here: ``` > formals(args(`[`)) NULL *Warning message:In formals(fun) : argument is not a function* > is.function(`[`) [1] TRUE > is.primitive(`[`) [1] TRUE ``` Now with an other primitive: ``` > formals(args(`sum`)) $... $na.rm [1] FALSE > is.function(`sum`) [1] TRUE > is.primitive(`sum`) [1] TRUE

Just checking in to see whether it is intended or not that assigning new formals to a function/closure causes any attributes to be dropped: EXAMPLE: > fcn <- structure(function() {}, foo="foo", class=c("foo")) > str(fcn) function () - attr(*, "srcref")=Class 'srcref' atomic [1:8] 1 18 1 30 18 30 1 1 .. ..- attr(*, "srcfile")=Classes

First, here's the specific bug I have. Later I'll say why I care. > ls(zappo) Error in try(name) : object "zappo" not found # good. > f = function(zappo) { function(y) zappo + y } > g = f(1) > g(1) [1] 2 > formals(g) $y > formals(g)$y > formals(g)$y = 2 > g function (y = 2) zappo + y > g(1) Error in g(1) : object "zappo" not found

I'm proposing to signal an error (from R >= 3.3.0) in such examples -- which do "work" in R 3.2.x and earlier : > f <- NULL; body(f) <- quote(sin(a+1)); f function () sin(a + 1) <environment: 0x48f9798> > g <- NULL; formals(g) <- alist(x = pi, y=); g function (x = pi, y) NULL <environment: 0x4e6dfe8> > The proposal is that the underlying C

The assignment form of 'formals' strips attributes (or something close to that) from the values in the list. This wasn't intentional, was it? The current behavior (2.0.0 through 2.1.0 on Windows at least): > fjj <- function() x > formals(fjj) <- list(x=c(a=2, b=4)) > fjj function (x = c(2, 4)) x Previous behavior: > fjj <- function() x > formals(fjj)

Dear list, I'm facing an issue with the automated documentation of a function using roxygen2. The function has a complex-valued default argument, which is picked up by roxygen2 using formals() to generate the corresponding Usage section of the Rd file. Unfortunately, it appears that formals() reformats complex numbers. Consider the example below, test <- function(a = 1+2i){} >

Dear Group: I want to create a function having a ... argument and to have the default arguments evaluated, as thus: g <- function(a, b, ...) a+b formals(g) <- alist(a=,b=2+3,...=) g function (a, b = 2 + 3, ...) a + b But I want the default argument for b to be evaluated as 5. How can this be done? Note: My real need is for a more complex expression to be evaluated for the default

Hi, I have a tiny question about the graphics change in R 2.7.0. If I write a script ? la: options(device="pdf") formals(pdf)[c("file","onefile","width","height")] <- list("~/Rplot %03d.pdf", FALSE, 8, 8) plot(3) plot(4) both plots will be written into ONE pdf file. (not two as expected) This worked fine under 2.6.x In R 2.7.0 I

On SVN revision 41087: ?args has this example line: args(c) # -> NULL (c is a 'primitive' function) The comment seems out of date, as args(c) does in fact have a non-NULL return value: args(c) # function (..., recursive = FALSE) # NULL While at it, I was wondering, why formals(c) still returns NULL, in contrast. Regards Thomas Friedrichsmeier -------------- next