What's the Difference in Using a Semicolon or Explicit New Line in R Code

What's the difference in using a semicolon or explicit new line in R code

At the console, the script is evaluated as soon as the a line ends with a complete statement. Hence, this:

temp_a 
temp_b <- 1 
temp_c <- 2

is equivelent to calling this:

source(textConnection('temp_a'))
source(textConnection('temp_b <- 1'))
source(textConnection('temp_c <- 2'))

in which each line is evaluated as soon as it is encountered, and failures
in previous lines don't prevent the subsequent lines from being evaluated.
On the other hand. this:

temp_a ; temp_b <- 1 ; temp_c <- 2

is equivalent to calling this:

source(textConnection('temp_a ; temp_b <- 1 ; temp_c <- 2'))

which is equivalent to this

source(textConnection('
temp_a  
temp_b <- 1 
temp_c <- 2'))

because when first line fails, the remainder of the code is not run.

Incidentally, if you want to mimic this behavior at the console, you can
take advantage of the fact that the lines are not evaluated until they make
a complete statement, by surrounding the three lines with braces to make a
single code block that is evaluated as a whole, like so:

{
    temp_a 
    temp_b <- 1 
    temp_c <- 2
}

Problems in creating function in R

To expand from my comment:

In R you have to separate statements either with ; (semicolon) or with a newline.

So this works:

avg <- function(x) { s <- sum(x); n <- length(x); s/n }
avg(c(1, 2, 3))
#[1] 2

As does this

avg <- function(x) { 
    s <- sum(x)
    n <- length(x)
    s/n 
}
avg(c(1, 2, 3))
#[1] 2

To pre-empt the question "What's the difference?", see the following post: What's the difference in using a semicolon or explicit new line in R code
.

variable-assignment: Difference between - and = in a certain post & avoiding using return

From ?return:

If the end of a function is reached without calling return, the value of the last evaluated expression is returned.

For example,

f <- function() {
   x <- 1
   x
}

is equivalent to the same function with return(x) as the last statement. Perhaps surprisingly,

f <- function() {
   x <- 1
}

also returns the same value, but returns it invisibly. There is a minor schism (perhaps not quite as strong as the = vs. <- schism) about whether it's better practice to always use an explicit return(): I believe it is good practice (because it makes the intention of the code more explicit), but many old-school R programmers prefer the implicit return value.

Odd behaviour of quotient in R

I am not sure, but it was too long for a comment. From ?"%%":

%% and x %/% y can be used for non-integer y, e.g. 1 %/% 0.2, but the
results are subject to representation error and so may be
platform-dependent. Because the IEC 60059 representation of 0.2 is a
binary fraction slightly larger than 0.2, the answer to 1 %/% 0.2
should be 4 but most platforms give 5.

why can't i update a record with each separator and field on a new line?

The semicolon must be at least more indented than the with

// as is this code won't compile (multiple definition of y)
let r' =
    { r with x = r.x + 1
           ; y = r.y + 2  // correct
         ;   y = r.y + 2  // correct
        ;    y = r.y + 2  // error
    }

Alternatively you could replace the with expression with it's equivalent but you then have to be explicit about all the fields (which can be tedious) :

let r' = r in // not sure where you would put that bit
    { x = r.x + 1
    ; y = r.y + 2
    ; z = r.z
    }

But, as said by rmunn all those semicolons are optional with a vertical alignment

Remove unwanted symbols from expression function - R

If this is about dynamically generating/formatting an output string, you can also use stringr::str_interp:

# Sample data
set.seed(2017);
df <- data.frame(x = c(1:100))
df$y <- 2 + 3 * df$x + rnorm(100, sd = 40)

# Fit
m <- lm(y ~ x, df);

# Extract coefficients and generate string
a <- coef(m)[1];
b <- coef(m)[2];
r2 <- summary(m)$r.squared;
stringr::str_interp("y = $[2.0f]{a} + $[2.0f]{b} x, R2 = $[4.3f]{r2}")
#[1] "y =  9 +  3 x, R2 = 0.793"

Or use sprintf:

sprintf("y = %2.0f + %2.0f x, R2 = %4.3f", a, b, r2);
#[1] "y =  9 +  3 x, R2 = 0.793"

What is the difference between := and = in Go?

= is assignment. more about assignment in Go: Assignments

The subtle difference between = and := is when = used in variable declarations.

General form of variable declaration in Go is:

var name type = expression

the above declaration creates a variable of a particular type, attaches a name to it, and sets its initial value. Either the type or the = expression can be omitted, but not both.

For example:

var x int = 1
var a int
var b, c, d = 3.14, "stackoverflow", true

:= is called short variable declaration which takes form

name := expression

and the type of name is determined by the type of expression

Note that: := is a declaration, whereas = is an assignment

So, a short variable declaration must declare at least one new variable. which means a short variable declaration doesn't necessarily declare all the variables on its left-hand side, when some of them were already declared in the same lexical block, then := acts like an assignment to those variables

For example:

 r := foo()   // ok, declare a new variable r
 r, m := bar()   // ok, declare a new variable m and assign r a new value
 r, m := bar2()  //compile error: no new variables

Besides, := may appear only inside functions. In some contexts such as the initializers for "if", "for", or "switch" statements, they can be used to declare local temporary variables.

More info:

variable declarations

short variable declarations

Why can you use multiple semicolons in C?

A semicolon terminates a statement... consecutive semicolons represent no-operation statements (as you say). Consider:

while (x[i++] = y[j++])
    ;

Here, all the work is done in the loop test condition, so an empty statement is desirable. But, empty statements are allowed even when there is no controlling loop.

Why?

Well, many uses of the preprocessor may expand to some actual C code, or be removed, based on some earlier defines, but given...

 MY_MACRO1();
 MY_MACRO2();

...the preprocessor can only replace the MY_MACROX() text, leaving the trailing semicolons there, possibly after an empty statement. If the compiler rejected this it would be much harder to use the preprocessor, or the preprocessor calls would be less like non-preprocessor function calls (they'd have to output semicolons within the substitution, and the caller would have to avoid a trailing semicolon when using them) - which would make it harder for the implementation to seemlessly substitute clever macros for functions for performance, debugging and customisation purposes.

---

Related Topics