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.

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