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.