Thanks … but I still have the same issue. All known test cases pass, your 4 examples pass, but I have the hidden “validator 3” which fails.
Any chance that @nicola1 or anyone who succeeded posts similar tests to validator 3 and 4 ?
I think the different error cases are not very clear. Which stack do we keep when adding “ERROR” to the stack in the different cases ?
It’s one of those too-old-can’t-edit puzzles 
I both solved and have access to the answers, but I’m afraid validators 3 and 4 don’t have anything to do with the matching test. So much for puzzle-authoring recommendations.
So, here’s some stuff, in random order, that could help you (do say so if it does, we might just as well lobby to have them added as test cases)
Understanding ROL
1 2 3 4 5 6 0 7 8 3 ROL should yield 1 2 3 4 5 6 7 8 0
1 2 0 3 4 5 6 7 8 7 ROL should yield 1 2 3 4 5 6 7 8 0
0 1 2 3 4 5 6 7 8 100 ROL should yield 0 1 2 3 4 5 6 7 8 ERROR (this one is fantastic: unspecified, not in the tests, but present in the validators)
Understanding error cases (specification-wise, those really are the worst. “if this happens, stop” is so “I’m describing my personal implementation, good luck with yours” 
)
1 ADD should yield ERROR
SUB should yield ERROR
0 MUL should yield ERROR
42 1 0 MOD should yield 42 ERROR (and not 42 1 ERROR, which IMHO would have been absolutely reasonable)
Understanding DUP (I just realized this one too is in validators but not tests)
1 DUP should yield 1 1
No because MOD is a binary operation that needs two numbers. It picks two numbers on the stack.
I’m glad it’s clear to you, but I’m afraid your position as the problem author makes you a bit too biased for us to read so much into your opinion about what makes sense.
The reason people doubt and come ask here is because the statement is ambiguous. Compare the three cases I’ve shown of ERROR, (ADD and MUL are the same), they all pop a different number of arguments. All the statement has to say about ERROR handling is “If an instruction has fewer operands than needed or if we try to divide by 0, append ERROR to the stack, print it and stop the program.”. In no way does it specify whether or not you’re supposed to pop operands in order to determine the error condition.
let us know if there is a change to be done in the statement or the tests as it’s a too-old-can’t-edit puzzle.
The puzzle was edited not by me because in the first version, for example, the ROL operator permuted not only three operands but the number it consumed. 5 ROL rolled five numbers.
Yes, that part is very ridiculous now. But I’ve checked the tests and validators: as far as I can tell, all of them are 3 or equivalent. So, ridiculous, but not wrong. How it came to become this way is beyond me.
Thanks a lot, I finally made it !
Here are the tests I used to test my code :
Solution.result("18 42 7 ROL") shouldBe "18 42 ERROR"
Solution.result("1 3 ADD") shouldBe "4"
// "forum tests from dubicube"
Solution.result("10 2 DIV") shouldBe "5"
Solution.result("23 42 36 0 DIV") shouldBe "23 42 ERROR"
Solution.result("18 42 8 3 ROL") shouldBe "42 8 18"
// "forum tests from JBM"
Solution.result("1 2 3 4 5 6 0 7 8 3 ROL") shouldBe "1 2 3 4 5 6 7 8 0"
// Solution.result("1 2 0 3 4 5 6 7 8 7 ROL") shouldBe "1 2 3 4 5 6 7 8 0"
// Solution.result("0 1 2 3 4 5 6 7 8 100 ROL") shouldBe "0 1 2 3 4 5 6 7 8 ERROR"
Solution.result("1 ADD") shouldBe "ERROR"
Solution.result("SUB") shouldBe "ERROR"
Solution.result("0 MUL") shouldBe "ERROR"
Solution.result("42 1 0 MOD") shouldBe "42 ERROR"
Solution.result("1 DUP") shouldBe "1 1"
I was missing the DUP implementation probably.
Howver I had to change the ROL implementation (the tests are commented above), when I implemented like you specified (below) it failed the validators.
I think the validators are consistent with the spec saying that it always ROLs the 3d number.
They’re both valid as (cf my other message above) it’s always effectively used with an argument of three.
Passing all “community” tests posted here, but still won’t pass the 3rd validator D:
This puzzle should really be removed or archived in some way and replaced with a more clear one if it’s not possible to edit it.
I love the idea of the puzzle though!
CG are thinking about fixing this bug.
There is still a major issue with this puzzle. I know several codingamers that are unable to achieve 100% due to a very strange bug.
First, the statement on
is NOT the same as the one I can see in the contributions ( https://www.codingame.com/contribute/view/116d0fa94976711d074284d72c2ce3991d4 ).
This is a serious issue since the two definitions for the ROL instruction do not have the same semantics. These definitions are the same only when the value on top of the stack is 3.
Second, I think that the real validators are not the one we can see on the contribution page. Depending on the code I try, I get either 80% in the IDE (looking only at the five validators from the contribution page) and 100% at submit, or 100% in the IDE and 80% at submit.
That being said, the simplest fix I see is to remove test 5 and validator 5:
- Validator 5 is the only place where we have a ROL with a parameter that is not 3.
- Validator 5 is also the only place where a ROL instruction fails.
- Validator 5 (either the one from the contribution or the one at submit) is responsible for the previous 80%.
- The main features have already been tested in the previous tests/validators.
3 Likes
I removed Test5/Validator5, I also synced the statement between contribution/puzzle (with the latest version) and make the contribution editable for further changes.
4 Likes
Hi Nicola, thanks for this nice puzzle.
First of all I would like you to know that this reverse polish notation puzzle is a great idea, it gives every student on occasion to pratice something very fundamental.
But, it is a little bit to easy compared to the other hard puzzles. I think it should be moved to the medium puzzles.
And it seems to me that the tests cases are not relevant enough. Every operator shoud be tested once. For instance, the ROL operator, which is a little bit tricky, should be tested in both a test case and a validation case.
Thanks again and have fun on coding game !
The Purificator.
1 Like
ROL passes the tests, when it eats the top number, and permutes the next 3.
Continuing the discussion from [Community Puzzle] Reverse Polish Notation:
Hello, for me, it’s validator 2 that refuses my code. I tested all the examples added above and all are validated by my algorithm. Does anyone have an idea. I can send my code privately. Thanks for the help.
Why making a separate forum thread and not ask the question there?
Anyhow, validator 2 contains four different operations, also negative and positive numbers. Two operations are immediately next to each other.
Try to solve this as a custom IDE test. This is NOT the validator (which I don’t want to publish here), but same structure just different numbers:
9
-3 5 4 MUL ADD 5 SUB 3 DIV
The output should be a single number.
(Moved back the last two posts to this forum thread.)
I had reversed x and y for the ‘sub’ operation, I could not check from the ‘test sets’ because there is no example of ‘sub’, while yes in validator 2.
It is fixed now and OK.
Thanks a lot.