In this community puzzle, I find the description and IDE tests really not enough
It took me lots of trials and errors to understand that the operations SUB, DIV, MOD use the arguments in the opposite order I was expecting, and this is only tested in a complex tests in the end.
The ROL description is also unclear. It would help to have examples with stack top to bottom instead left to right, so we understand what the top of stack means.
Finally, even when I got all IDE tests to pass, I still have 2 failing tests after submitting. I guess my handling of ERROR when something is still on the stack is not correct, but again the IDE tests are not enough to understand precisely what is expected.
Iād appreciate some clarifications on the subject. It would be great to have a direct way to comment and ask for clarifications on these community puzzles ā¦ The quality of the subjects and tests is not always as good as for the official ones !
Initially, when I wrote this puzzle, the ROL function picked the first number N on the stack then rolls N times from this number.
Now (itās not my choice), it still picks the first number on the stack but rolls thrice.
Yep, I understood so finally.
What about the error handling ? what should be popped from the stack and what should be left before we push āERRORā ?
Now I got 4/5 validators to pass when I submit, but āValidator 3ā still fails ā¦ and with such a name itās difficult to guess what is wrong compared to the IDE validators.
Aha, thank you, thatās why one test kept failing. Maybe if there was an IDE test involving a division error itād be more clear? For ānot enough argumentsā error, only āERRORā is printed, so itās not really clear whatās happening.
Apart from that, the IDE tests seem to be not quite thorough. There are many possible configurations, and itās probably not possible to test them all, but adding a minimal test for at least all basic operators (DIV, POP and DUP seem to be missing) could be a good idea.
I also had a problem with validator 05 (āValidator 4ā). The answer can be found in the discussion above.
The desired handling of a division by zero error is:
Pop two numbers out of the stack.
Push āERRORā onto the stack instead of a number.
Stop taking inputs.
Output the entire stack.
For example, the input ā1 2 3 0 DIVā has output ā1 2 ERRORā.
And what about handling ROL errors? Should I print only ERROR when there are less than 4 items in the stack?
My solution works as follow: 1 2 3 4 ROL -> 2 3 1 1 2 3 ROL -> ERROR 1 2 ROL -> ERROR 1 ROL -> ERROR ROL -> ERROR
So as I understood, the only case when stack contains something besides ERROR is when division by zero occurs.
Is this correct or validators expect different behavior?
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)
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.
)