Cannot declare and define an integer array using the colon operator

[alashworth]

Issue by bgoodri Saturday Oct 21, 2017 at 22:48 GMT Originally opened as https://github.com/stan-dev/stan/issues/2424

---

Summary:

It is a parser error to declare and define a one-dimensional integer array using the colon operator.

Description:

It is a parser error to declare and define a one-dimensional integer array using the colon operator.

Reproducible Steps:

Try to parse the following Stan program

data {
  int<lower=1> K;
}
transformed data {
  int arr[K] = 1:K;
}

Current Output:

SYNTAX ERROR, MESSAGE(S) FROM PARSER:

variable definition dimensions mismatch, definition specifies 1, declaration specifies 0  error in 'model_int_array' at line 5, column 17
  -------------------------------------------------
     3: }
     4: transformed data {
     5:   int arr[K] = 1:K;
                        ^
     6: }
  -------------------------------------------------

Error in stanc(model_code = paste(program, collapse = "\n"), model_name = model_cppname,  : 
  failed to parse Stan model 'int_array' due to the above error.

Expected Output:

Nothing. It should assign the integers from 1 to K to arr

Additional Information:

Current Version:

v2.17.0

[alashworth]

Comment by bob-carpenter Saturday Oct 21, 2017 at 23:13 GMT

---

This sounds like it'd be reasonable to add. It shouldn't be too hard. : will have to be defined as an infix operator.

What should its precedence be? It would make sense to me to allow 1+2:3 + 9 with interpretation (1 + 2):(3 + 9)? R goes the other way (for all arithmetic), making : bind more tightly:

> 1+2:3+4
[1] 7 8

Associativity doesn't matter since it's output isn't the same type as its input.

[alashworth]

Comment by bgoodri Sunday Oct 22, 2017 at 00:02 GMT

---

I guess it should be whatever it is for x[1 + 2:3 + 9].

On Sat, Oct 21, 2017 at 7:13 PM, Bob Carpenter notifications@github.com wrote:

This sounds like it'd be reasonable to add. It shouldn't be too hard. : will have to be defined as an infix operator.

What should its precedence be? It would make sense to me to allow 1+2:3 + 9 with interpretation (1 + 2):(3 + 9)? R goes the other way (for all arithmetic), making : bind more tightly:

1+2:3+4 [1] 7 8

Associativity doesn't matter since it's output isn't the same type as its input.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/stan-dev/stanc3/issues/1404, or mute the thread https://github.com/notifications/unsubscribe-auth/ADOrql7_AYgLU3LB7Przg6z2en1Ar9F-ks5sunqYgaJpZM4QBvjF .

[alashworth]

Comment by bob-carpenter Sunday Oct 22, 2017 at 00:33 GMT

---

Excellent point. Current Stan treats : as binding more loosely than arithmetic. So we get 1 + 2 : 3 + 9 with the same denotation as 3 : 12 in both of the existing contexts:

  for (i in 1 + 2 : 3 + 9) ...

and

x[1+ 2 : 3 + 9]

[alashworth]

Comment by VMatthijs Thursday Dec 13, 2018 at 13:03 GMT

---

This is difficult to add to Stan currently as it would lead to ambiguity. For example, is the following a valid Stan program if we add this behaviour

model {
  int n = 5
  for (i in 1:n) {
    n += 1;
  }
}

?

Observe that the for could then either be interpreted as a for-loop over the range 1:n or a foreach-loop over the array 1:n. Both have slightly different operational semantics. Because our for-loops are like C for-loops, the upper bound gets reevaluated after each pass through the loop body. In particular, for-loops might not terminate. For foreach-loops, the array gets evaluated once before we enter the loop and then becomes immutable.

[alashworth]

Comment by bob-carpenter Thursday Dec 13, 2018 at 13:56 GMT

---

This program is currently valid and will evaluate the loop body for i in { 1, 3, 5 }.

With "1:n" this would be ambiguous between a foreach loop where "1:n" denotes an int[] and a regular loop where "1:n" are just the loop bounds.

This is a behavior we could change in Stan 3. I believe Matthijs has suggested making the loop bounds immutable in the body, so it's effectively the foreach interpretation.

his could get tricky syntactically if the bound is a function, say

for (i in 1:f(x,y,z))

We presumably wouldn't want any of x, y, z being mutated in the loop body. This would settle on the foreach s

On Dec 13, 2018, at 8:03 AM, Matthijs Vákár notifications@github.com wrote:

This is difficult to add to Stan currently as it would lead to ambiguity. For example, is the following a valid Stan program if we add this behaviour

model { int n = 5 for (i in 1:n) { n += 1; } }

?

Observe that the for could then either be interpreted as a for-loop over the range 1:n or a foreach-loop over the array 1:n. Both have slightly different operational semantics. Because our for-loops are like C for-loops, the upper bound gets reevaluated after each pass through the loop body. In particular, for-loops might not terminate. For foreach-loops, the array gets evaluated once before we enter the loop and then becomes immutable.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.