Cannot declare and define an integer array using the colon operator
Opened this issue · 5 comments
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
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.
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 8Associativity 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
stan-dev/stanc3#1404, or mute
the thread
https://github.com/notifications/unsubscribe-auth/ADOrql7_AYgLU3LB7Przg6z2en1Ar9F-ks5sunqYgaJpZM4QBvjF
.
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]
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.
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.