similar to: identical(..., ignore.environment=TRUE)

On 11/10/2015 10:36 PM, Duncan Murdoch wrote: > On 11/10/2015 8:05 PM, Ben Bolker wrote: >> >> It seems odd/inconvenient to me that the "ignore.environment" argument >> of identical() only applies to closures (which I read as 'functions' -- >> someone can enlighten me about the technical differences between >> functions and closures if they like

On 12/10/2015 9:51 AM, Ben Bolker wrote: > Duncan Murdoch <murdoch.duncan <at> gmail.com> writes: > > BB> >>>> It seems odd/inconvenient to me that the "ignore.environment" argument >>>> of identical() only applies to closures (which I read as 'functions' -- >>>> someone can enlighten me about the technical differences

MM> but I don't think we'd want to MM> change all.equal.language() at this point in time Although it would be nice if all.equal looked at least at attributes of formulas so we did not get results like > form <- y ~ x1 %in% x2 > all.equal(form, terms(form)) [1] TRUE > all.equal(terms(y~x1+x2+Error(x3/x2), specials="Error"), terms(y~x1+x2+Error(x3/x2)))

On 11/10/2015 8:05 PM, Ben Bolker wrote: > > It seems odd/inconvenient to me that the "ignore.environment" argument > of identical() only applies to closures (which I read as 'functions' -- > someone can enlighten me about the technical differences between > functions and closures if they like -- see below for consequences of my > confusion). This is

>>>>> Duncan Murdoch <murdoch.duncan at gmail.com> >>>>> on Mon, 12 Oct 2015 19:31:11 -0400 writes: > On 12/10/2015 9:51 AM, Ben Bolker wrote: >> Duncan Murdoch <murdoch.duncan <at> gmail.com> writes: >> BB> >>>>> It seems odd/inconvenient to me that the >>>>>

Duncan Murdoch <murdoch.duncan <at> gmail.com> writes: BB> > >> It seems odd/inconvenient to me that the "ignore.environment" argument > >> of identical() only applies to closures (which I read as 'functions' -- > >> someone can enlighten me about the technical differences between > >> functions and closures if they like -- see

Specifically, the srcfile attribute of the srcref attribute of the two instances of the functions contain different environments, AFAICT. Environments are compared only by exact pointer, so this forces return FALSE. Snippets from .Internal(inspect(x)) and .Internal(inspect(y)): @cca008 03 CLOSXP g0c0 [MARK,NAM(2),ATT] FORMALS: @604b58 00 NILSXP g0c0 [MARK,NAM(2)] BODY: @cc9650 06 LANGSXP

On Mon, Sep 20, 2010 at 3:16 PM, Talin <viridia at gmail.com> wrote: > So I've managed to get my stack crawler working and passing its unit tests > - this is the one I've been working on as an alternative to shadow-stack: it > uses only static constant data structures (no global variables or > thread-local data), which means that it's fully compatible with a >

I'm confused by this: > identical(function() {}, function() {}) [1] FALSE Yet, after loading the Matrix package (which redefines det), the following is checked (in library.checkConflicts): > identical(get("det", baseenv()), get("det", asNamespace("Matrix")), ignore.environment=T) [1] TRUE I've looked at the code in identical.c and for closures it

I am trying to build a function in a context where the environment concept would appear to be useful. But I'm a bit foggy about this concept and would appreciate some pointers and advice. Basically the function I'm building, say foo(x,t), is a function of two variables). Depending on the value of t, foo will return one of the values f1(x), f2(x), ..., fk(x), where each of f1, ..., fk is

Hi, thx for the reply. Unfortunately that is not a simplified version of the problem. You have a function, call it and get the result (numeric in, numeric out in that case). For simplicity lets use the "return" case: ## foobar<-function(x) { return(sqrt(x)) }(2) ## which is a function (numeric in, numeric out) which is defined, then gets called and the return value is a function

Code like df <- data.frame(x=1:10) y <- 20:29 eval(quote(x+y), env=df) does what you might expect: it looks for x and y in the data.frame, and when it doesn't find y there, it looks in the parent environment. However, sometimes I'd like to construct a single environment out of df, so that I can pass it to nested functions and get the same behaviour. Right now, I get the wrong

Code like df <- data.frame(x=1:10) y <- 20:29 eval(quote(x+y), env=df) does what you might expect: it looks for x and y in the data.frame, and when it doesn't find y there, it looks in the parent environment. However, sometimes I'd like to construct a single environment out of df, so that I can pass it to nested functions and get the same behaviour. Right now, I get the wrong

I'm using specify.model for the sem package. I can't figure out how to represent the residual errors for the observed variables for a CFA model. (Once I get this working I need to add some further constraints.) Here is what I've tried: model.sa <- specify.model() F1 -> X1,l11, NA F1 -> X2,l21, NA F1 -> X3,l31, NA F1 -> X4,l41, NA F1 -> X5, NA, 0.20

This is just my curiousity working. Suppose I write: f1 <- function(x) x + 1 f2 <- function(x) 2 * f1(x) f2(10) # 22 f1 <- function(x) x - 1 f2(10) # 18 This is quite obvious. But is there any way to define f2 in such a way that we "freeze" the definition of f1? f1 <- function(x) x + 1 f2 <- function(x) # put something here 2 * f1(x) # probably put something else here

Hi. I have defined a function, f1, that calls another function, f2. Inside f1 an intermediate variable called nm1 is created; it is a matrix. f2 takes a matrix argument, and I defined f2 (schematically) as follows: f2<-function(nmArg1=nm1,...){nC<-ncol(nmArg1); ... } so that it expects nm1 as the default value of its argument. f1 is defined (schematically) as:

Despite the spirited arguments of various R-core folks who feel that mle() doesn't need a "data" argument, and that users would be better off learning to deal with function closures, I am *still* trying to make such things work in a reasonably smooth fashion ... Is there a standard idiom for "merging" environments? i.e., suppose a function has an environment that I want

Hi. I have tried to use Package "SEM". As a learning, I try to convert a program running well of EQS which is as follows to SEM: ### EQS ### /SPECIFICATION CAS=100; VAR=5 MAT=COR; ANA=COR; /EQUATIONS V1=*F1+E1; V2=*F1+E2; V3=*F1+*F2+E3; V4=**F1+*F2*E4; V5=*F2+E5; /VAR E1 TO E5=*; F1*1.0; F2=1.0; /COV E1,E2=*; F1,F2=*: /PRINT FIT ALL; /MATRIX ...... /END This is the converted SEM

Someone can help me? I tried several things and always don't converge # Model library(sem) dados40.cov <- cov(dados40,method="spearman") model.dados40 <- specify.model() F1 -> Item11, lam11, NA F1 -> Item31, lam31, NA F1 -> Item36, lam36, NA F1 -> Item54, lam54, NA F1 -> Item63, lam63, NA F1 -> Item65, lam55, NA F1 -> Item67, lam67, NA F1 ->

[AMD Public Use] Hi Oliver, I get rid of the warnings by explicitly type-casting it to struct*, and still get similar results. ####################################################### struct P { float f1; float f2; float f3[3]; float f4; }; void foo(struct P* p1, struct P* p2) { p1->f2 = 1.2; p2->f1 = 3.7; } int callFoo() { struct P p; foo(&p,