similar to: environments

On Jun 2, 2008, at 11:11 PM, Tanya Lattner wrote: > Darwin/ppc: > SingleSource/Benchmarks/CoyoteBench/fftbench [ CBE ] > From what I can see comparing 2.3 with TOT, the "cexp" function is declared like this in 2.3: declare i128 @cexp({double, double}* byval) nounwind It used to be this: declare void @cexp({double, double}* noalias sret, {double, double}* byval)

Dear members, I have the following code: > TB <- {x <- 3;y <- 5} > TB [1] 5 It is consistent with the documentation: For {, the result of the last expression evaluated. This has the visibility of the last evaluation. But both x AND y are created, but the "return value" is y. How can this be advantageous for solving practical problems?

I am more than a little puzzled by your question. In the construct {expr1; expr2; expr3} all of the expressions expr1, expr2, and expr3 are evaluated, in that order. That's what curly braces are FOR. When you want some expressions evaluated in a specific order, that's why and when you use curly braces. If that's not what you want, don't use them. Complaining about it is like

Hello Akshay, R is quite inspired by LISP, where this is a common thing. It is not in fact that {...} returned something, rather any expression evalulates to some value, and for a compound statement that is the last evaluated expression. {...} might be seen as similar to LISPs (begin ...). Now this is a very different thing compared to {...} in something like C, even if it looks or behaves

R's { expr1; expr2; expr3} acts much like C's ( expr1, expr2, expr3) E.g., $ cat a.c #include <stdio.h> int main(int argc, char* argv[]) { double y = 10 ; double x = (printf("Starting... "), y = y + 100, y * 20); printf("Done: x=%g, y=%g\n", x, y); return 0; } $ gcc -Wall a.c $ ./a.out Starting... Done: x=2200, y=110 I don't like that

Many of you are probably wondering about the status of the 2.3 release. Unfortunately, this release has been very difficult and the list of regressions very high. The list has finally dwindled down to the following regressions: Linux/x86: SingleSource/Benchmarks/CoyoteBench/fftbench [ JIT Codegen, JIT] MultiSource/Applications/minisat/minisat [CBE] Darwin/x86:

I'm getting an error from nlme that has me stymied. I have a data set ,'mydata', with variables: AChE, Dose, sex, set, and mrid; 'set' and 'mrid' indicate two levels of nesting, with 'set' nested within 'mrid'. I want to fit the model: mod <- nlme(AChE ~ Cexp(Dose, A, B, m), data=mydata, fixed = A+B+M~sex, random=A+B+m~sex | mrid/set,

Today I tried two build R-devel_2011-02-06.tar.gz from sources on FreeBSD 9.0-CURRENT (amd64) with gcc-4.5.2 and I got the following messages when configuring: ./configure [..SNIP..] checking whether C99 double complex is supported... checking complex.h usability... yes checking complex.h presence... yes checking for complex.h... yes checking for double complex... yes checking whether cexp

First, thanks to all who helped me with my question about rescaling axes on the fly. Using unlist() and range() to set the axis ranges in advance worked well. I've since plotted about 300 datasets with relative ease. Now I'm trying to fit a lossy oscillator resonance to (the square root of) a lorentzian (testframe$y is oscillator amplitude, testframe$x is drive frequency): lorentz

R-users, Has anyone implemented (coded) the Rai and Van Ryzin dose-response model from their 1985 Biometrics paper. I'm trying to avoid re-inventing the wheel. If not any hints on coding this would be greatly appreciated. Thanks, -- ==================== Calvin L. Williams, Ph.D. ==================== Department of Mathematical Sciences, Clemson University

> From what I can see comparing 2.3 with TOT, the "cexp" function is > declared like this in 2.3: > > declare i128 @cexp({double, double}* byval) nounwind > > It used to be this: > > declare void @cexp({double, double}* noalias sret, {double, double}* > byval) nounwind The promotion from a void function with an sret argument to a function returning

Unless you do something special within a function, only the value(s) returned are available to the caller. That is the essence of functional-type programming languages. You need to read up on (function) environments in R . You can search on this. ?function and its links also contain useful information, but it may too terse to be explicable to you. There are of course many available references on

Dear Valentin, But why should {....} "return" a value? It could just as well evaluate all the expressions and store the resulting objects in whatever environment the interpreter chooses, and then it would be left to the user to manipulate any object he chooses. Don't you think returning the last, or any value, is redundant? We are living in the 21st century

?s 14:47 de 09/01/2023, akshay kulkarni escreveu: > Dear members, > I have the following code: > >> TB <- {x <- 3;y <- 5} >> TB > [1] 5 > > It is consistent with the documentation: For {, the result of the last expression evaluated. This has the visibility of the last evaluation. > > But both x AND y are created, but the

Perhaps the following may be of use to you. Consider: > f <- function(){ x <- 3; function(y) x+y} > x <- 5 ##What does this give? > f() ## Why? ## How about this? >f()(10) ## Why? ## If you remove "x <- 3" from the above, what will you get when you repeat the exercise? -- Bert On Mon, Jan 9, 2023 at 8:29 AM Bert Gunter <bgunter.4567 at gmail.com>

The configure script runs fine, but when I compile todays alpha version of R-2.2.0 (R-alpha_2005-09-10_r35546.tar.gz) under FreeBSD 7.0-CURRENT from Sept. 4th I get the following output: ======================================================== [...] gcc -I../../src/extra/zlib -I../../src/extra/bzip2 -I../../src/extra/pcre -I. -I../../src/include -I../../src/include -I/usr/local/include

I suspect akshay is (or was? Not sure) unclear about what braces do. They are not closures... they create an expression that wraps multiple expressions into one expression... they are a little more like parentheses than closures. They are not intrinsically associated with creation of environments for holding variables. Functions are closures... they run in a call-specific environment that

Returning the last value of { is the basis of functions not needing a return statement. Before R invokes a function (specifically a closure), it creates a new context. When R evaluates a call to return, it looks for a context to return from and finds the context of function, ending the context and the evaluation of the function body early. However, if you don't use return, R just returns the

I wonder if the real confusino is not R's scope rules? (begin .) is not Lisp, it's Scheme (a major Lisp dialect), and in Scheme, (begin (define x ...) (define y ...) ...) declares variables x and y that are local to the (begin ...) form, just like Algol 68. That's weirdness 1. Javascript had a similar weirdness, when the ECMAscript process eventually addressed. But the real

Akshay, Your question seems a tad mysterious to me as you are complaining about NOTHING. R was designed to return single values. The last statement executed in a function body, for example, is the value returned even when not at the end. Scoping is another issue entirely. What is visible is another discussion. So, yes, if you can see ALL the variables, you might see the last one BUT there