similar to: incorrect behaviour of formals (PR#4511)

Full_Name: Jörg Polzehl Version: 1.5.1 OS: Windows 2000 Submission from: (NULL) (193.175.148.198) When calculating MLE's in a variance component model using constrained optimization, i.e. optim(...,method="L-BFGS-B",...) I observed an inproper behaviour in cases where the likelihood function was evalueted at the constraint. Parameters and value of the function at the constraint

--=====================_24736660==_ Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable SVD-Error on R 1.1.0 Windows 98 I get the following error applying svd on a positive definite matrix : > sk2 [,1] [,2] [,3] [,4] [,5] [1,] 1.0460139783 0.084356992 -2.810553e-04

Full_Name: Joerg Polzehl Version: 0.90.1 OS: Digital UNIX V4.0F Submission from: (NULL) (192.124.249.126) The dimension attribute in function density is not handled correctly (or at least differently from S) : z_rnorm(1000) dim(z)_c(10,10,10) plot(density(z),type="l") # no problem plot(density(z[1,,]),type="l") # Error in if (!(lo <- min(hi, IQR(x)/1.34))) (lo <-

Full_Name: Joerg Polzehl Version: 2.3.1 OS: x86_64, linux-gnu Submission from: (NULL) (62.141.176.22) I observed an incorrect behavior of function deriv when evaluating arguments of dnorm deriv(~dnorm(z,0,s),"z") expression({ .value <- dnorm(z, 0, s) .grad <- array(0, c(length(.value), 1), list(NULL, c("z"))) .grad[, "z"] <- -(z * dnorm(z))

Dear Colleagues, I've recently upgraded to SUSE-LINUX 9.0 and R 1.8.1 (using the RPM-'s from CRAN). I've checked that all required LINUX-Packages as listet in the README.html in /bin/linux/SUSE are installed. I've then tried to INSTALL and check a package. Installation with R CMD INSTALL -l Rcontrib aws * Installing *source* package 'aws' ... ** libs make:

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 :

CRAN (and crantastic) updates this week New packages ------------ * bisectr (0.0.2) Maintainer: Winston Chang Author(s): Winston Chang <winston at stdout.org> License: GPL-2 http://crantastic.org/packages/bisectr Tools to find bad commits with git bisect * CUMP (1.0) Maintainer: Xuan Liu Author(s): Xuan Liu <liuxuan at bu.edu> and Qiong Yang <qyang at bu.edu>

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

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

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

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

Hi, I am a little bit surprised by the following output of 'formals'. Is this the intended behavior? > f <- function(a=1,b=-1) { a+b } > class(formals(f)$a) [1] "numeric" > class(formals(f)$b) [1] "call" Josef -- ----------------------------------------------------------------------------- Josef Leydold | WU (Vienna University of Economics and

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){} >

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

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

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

Hello, This is because args(`[`) returns NULL and class(NULL) is NULL. So the question would be why is the return value of args(`[`) NULL? Rui Barradas ?s 15:14 de 07/10/2018, Peter Dalgaard escreveu: > > >> On 7 Oct 2018, at 16:04 , Rui Barradas <ruipbarradas at sapo.pt> wrote: >> >> Hello, >> >> I don't see why you say that the documentation

Hello, I don't see why you say that the documentation seems to be wrong: class(args(`+`)) #[1] "function" args() on a primitive does return a closure. At least in this case it does. Rui Barradas ?s 14:05 de 07/10/2018, Peter Dalgaard escreveu: > There is more "fun" afoot here, but I don't recall what the point may be: > >> args(get("+"))

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