[Community Puzzle] Reverse Polish Notation

In this community puzzle, I find the description and IDE tests really not enough :frowning:

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 !

1 Like

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” ?

The numbers that should be used are popped (the two operands for a division by zero).

Thanks for the clarification !

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.

Apart from its tests, the puzzle is very nice! :smiley:

Yup, it makes the operation a bit weird…


What could be the reason of failure in Validator 4?

Thanks in advance.

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


I’ve been stuck with the validator 03 for a while, still don’t find the solution.

Any help ?

1 Like

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?

This is correct, I’ll check if these cases are tested.

For those who are stuck with some validators I suggest them to test these testcases(the third line is the out):

  • 3
    10 2 DIV
  • 5
    23 42 36 0 DIV
    23 42 ERROR
  • 5
    18 42 8 7 ROL
    42 8 18
  • 4
    18 42 7 ROL

By the way testcases of this puzzle are really insufficient, but unfortunately it cannot be edited.

1 Like

Yes, the older puzzles can’t be edited even by its creator.

thanks a lot!

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 :frowning:
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: )

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.