https://www.codingame.com/training/medium/the-polish-dictionary
Send your feedback or ask for help here!
Created by @Gorbit99,validated by @Di_Masta,@Wei-1 and @VilBoub.
If you have any issues, feel free to ping them.
Not sure about those parenthesis rules, I assume they’re right but they are very confusing.
Somehow a * b / c / d * e is fine as is.
2 Likes
There seems to be either a problem with testcases or missing information in the problem statement. Taking testcase 4 (“Multiple Layers”) as an example, the given RPN notation:
5 3 + 10 * 8 4 + +
literally decodes as ((5 + 3) * 10) + (8 + 4), fully parenthesized. The parentheses around multiplication by 10 can be dropped because the outer operation (+) has lower priority. Unless you are doing algebraic simplification, the parentheses around (8 + 4) cannot be removed.
The expected answer is (5 + 3) * 10 + 8 + 4 groups as ((5 + 3) * 10 + 8) + 4, and that’s not the same order of operations. (The problem statement doesn’t say that like-priority operations group left-to-right, but that’s implied in testcase 7 where (a / b) / (c / d) is expected to simplify to a / b / (c / d).)
Rewriting a+(b+c) as (a+b)+c is an algebraic transformation. It’s not a matter of notation. The order in which numbers are combined has changed.
There’s nothing wrong with requiring this optimization for + and * with integer arguments, but it really should be mentioned in the problem statement.
It’s worth noting that floating point addition and multiplication are not associative. a + (b+c) and (a + b) + c can give different results due to rounding. Even in integers, there can be the problem that one of those might overflow when the other won’t.
3 Likes