ID:2382013
 
Resolved
The compiler made assumptions about optimizing certain expressions such as a + (b + c) that weren't necessarily correct.

Additionally, some operators like + * | & ^ pre-celculated the constant parts of their results, but it cannot be assumed that 1 + a + 2 is the same as a + 3 because of type mixing and operator overloading. The pre-calculation done by these operators has been improved to reflect this.
BYOND Version:512.1423
Operating System:Linux
Web Browser:Chrome 67.0.3396.87
Applies to:Dream Maker
Status: Resolved (512.1436)

This issue has been resolved.
Descriptive Problem Summary:
Brackets in addition and multiplication operations are ignored, leading to calculations potentially taking different values due to limited floating-point precision.

Numbered Steps to Reproduce Problem:
- Write an expression like a+(b+c)
- Execute it
- Observe that it was calculated as (a+b)+c

Code Snippet (if applicable) to Reproduce Problem:
/proc/show(x)
world.log << num2text(x, 10)

/world/New()
var/a = 16777216
var/b = 1
var/c = 1
show(a + b + c) // 16777216
show(a + (b + c)) // 16777216 - expect 16777218
show((b + c) + a) // 16777218

var/x = 1.0e38
var/y = 1.0e38
var/z = 1.0e-38
show(x * y * z) // inf
show(x * (y * z)) // inf - expect 9.999998666e+37
show((y * z) * x) // 9.999998666e+37

a = 1
b = "foo"
c = 2
// expect: runtime error: type mismatch: "foo" + 2
// actual: runtime error: type mismatch: 1 + "foo"
show(a + (b + c))


Expected Results:
For b + c or y * z to be calculated first, followed by a + result or x * result

Actual Results:
a + b or x * y is calculated first, followed by result + c or result * z

Does the problem occur:
Every time? Or how often? Every time
In other games? Yes
In other user accounts? Unknown
On other computers? Unknown

When does the problem NOT occur?
When you reorder your calculation such that left-to-right is the order you want.

Did the problem NOT occur in any earlier versions? If so, what was the last version that worked?
Unknown.

Workarounds:
Reorder the calculation to be e.g. b + c + a

This is a result of the way the compiler simplifies expressions, it should be feasible to change that,
Lummox JR resolved issue with message:
The compiler made assumptions about optimizing certain expressions such as a + (b + c) that weren't necessarily correct.

Additionally, some operators like + * | & ^ pre-celculated the constant parts of their results, but it cannot be assumed that 1 + a + 2 is the same as a + 3 because of type mixing and operator overloading. The pre-calculation done by these operators has been improved to reflect this.