Hello and thank you for your detailed example model.
\nThe first issue you encounter: having 11 instead of 2 is not really a bug but simply a problem of priority of operations. What is read by the interpreter is something like this:
\nwrite \"some string\" + <float> + <float>;\n
and the priority is this one:
\nwrite ( (\"some string\" + <float>) + float)\n
so in that context all +
are to be interpreted as concatenation and not addition. You don't see that with the multiplication example because the multiplication has a higher priority than the addition, and so
write \"some string\" + <float> * <float>;\n
resolves like this:
\nwrite (\"some string\" + (<float> * <float>));\n
and so the concatenation is done after floats are multiplied together.
\nYou can fix that by forcing the order yourself with parenthesis or using the sample
operator which will generate the prefixed string for you, for example:
write sample(foo[\"b\"] + 1);\n
Nonetheless your example underlined two real problems with manipulating maps of unknown objects:
\nI will create proper issues to track them down and hopefully fix this quickly, in the meantime a simple workaround for you will be to force cast in the code to the type you want to interact with (so instead of foo[\"a\"] + 123
, do int(foo[\"a\"]) + 123
).
-
Hello, I suppose I should just always cast mapped values to the right type while using them. Could someone explain me why I do get those strange behaviors though? consider the following code;
|
Beta Was this translation helpful? Give feedback.
-
Hello and thank you for your detailed example model. The first issue you encounter: having 11 instead of 2 is not really a bug but simply a problem of priority of operations. What is read by the interpreter is something like this:
and the priority is this one:
so in that context all
resolves like this:
and so the concatenation is done after floats are multiplied together.
Nonetheless your example underlined two real problems with manipulating maps of unknown objects:
I will create proper issues to track them down and hopefully fix this quickly, in the meantime a simple workaround for you will be to force cast in the code to the type you want to interact with (so instead of |
Beta Was this translation helpful? Give feedback.
Hello and thank you for your detailed example model.
The first issue you encounter: having 11 instead of 2 is not really a bug but simply a problem of priority of operations. What is read by the interpreter is something like this:
and the priority is this one:
so in that context all
+
are to be interpreted as concatenation and not addition. You don't see that with the multiplication example because the multiplication has a higher priority than the addition, and soresolves like this:
and so the concatenation is done a…