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.
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.
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)
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.