Coding Games and Programming Challenges to Code Better
Send your feedback or ask for help here!
Created by @jddingemanse,validated by @cedricdd,@Stef_3 and @Remi.
If you have any issues, feel free to ping them.
1 Like
Isnât there an ambiguity now with Jokers ?
For a run such as, 3R 4R 5R 6R 7R 8R 9R J, TAKE 6R can split in two ways, with the Joker part of either the first or the second part. Similarly, there are two options for PUT 5R into 3R 4R 5R 6R 7R J.
I guess this doesnât happen in tests, and even if it does, one can assume the âcorrectâ split so that further actions are OK, and the final groups match, but still, an additional (optional) argument to TAKE and PUT would be cleaner.
1 Like
Cool that you started on this puzzle 
.
I agree with you that there is technical ambiguity, since the J position is not fixed within a run. How I have it in mind, is that J is always at the most right position - except if it is required elsewhere. While not explicitly stated, for me this implies that, since for splitting 3R 4R 5R 6R 7R 8R 9R J with TAKE 6R, J is not required at any other position, it stays at its most right position - and hence automatically moves along with the right hand split. (TAKE 5R would only be possible if the J comes over to the left side, so only in that case J would move to the left hand split.)
More in general, this level of detail is in that grey area where I am not sure that added text to the statement to explicitly cover this, would actually help the statement or only make it less clear. Like you guess, this situation is not encountered in any of the cases currently (there are no long runs with a J in any of the input tables). Also, it would only be relevant in a case where the J starts in a long run, the run needs to be split as part of the solution, but J itself is not needed for the solution (if J would be needed later on, then the intermediate position of J is not relevant).
What do you mean with this regarding the cases you present? Do you mean to move J around explicitly with additional TAKE and PUT, or do you mean something else?
My thoughts regarding explicit J movement: I preferred the implicit movement of J to whatever place it is needed within a row, instead of explicit actions for moving J around within a row. Especially since such actions themselves would become ambiguous (to move J around explicitly within a same run with id 6, you would need something like TAKE J 6 ⌠PUT J 6, which is weird. Or we would need to introduce a specific position within a row as part of a command - but that would make the required output bigger (and additional statement text on how positions are numbered), which I donât like as well.
By the way
I think there might be more ambiguous cases that could be forced. For example, the case where you have 1R ... 12R J and you have to put away 13R. Technically, a run can only consist out of 13 tiles, so you could not have 1R ... 13R J. But then, where to make the split to put the J away? And with what command would you even split the row to make receiving the 13R possible?
There might be more ambiguous situations. I would say those ambiguous cases are linked to parsing/formatting: how do you finally display something? During creation of Rummikub 1 and 2 I made the decision to not explicitly test such formatting edge cases extensively, since they would require a more explicit coverage in the statement, to test them all would require much more cases, and in real life Rummikub they are not relevant at all.
Apologies for spilling over more thoughts than what you asked for. I have been brooding on this puzzle for some six months and then waited six months until it came live. Now others are diving into this as well, I cannot contain my thoughts 
.
Thanks for the detailed reply !
I was thinking of something along TAKE|PUT tile group [0|1] where the last argument (if present) tells in what part of the split to put the Joker. This is how Iâm currently adapting the code from part 1.
But after a bit more thoughts, I think itâs OK to just leave at the end unless needed at the start. If a solution requires the Joker in the first group, well thatâs just an additional move of the Joker, which may make a solution âartificiallyâ longer, but thatâs not really a problem. And it will allow me to simplify a bit my code 
Regarding your âBy the wayâ, I donât think itâs really in the same class : there the issue is that you have multiple âequivalentâ solutions with no rule to prefer one over another. But thatâs covered by âCases have been constructed such that there is always only one solution after following the action selection and order rules.â, whereas an ambiguity in the meaning of a move is a bit more serious.
2 Likes
You made me thinking about cases where this would matter - and this led me to a valid case for which indeed the âleaving J at the rightâ requires an artificially longer solution. I see your point now - good catch!
The following case:
9R
2
1 3R 4R 5R 6R 7R 8R 9R J
2 7B 7G 7R 7Y
with leaving J at the right side after inserting 7R leads to the following solution steps:
TAKE 7R 2
PUT 7R 1
TAKE J 3
PUT J 1
PUT 9R 1
while, if there would be some implementation of your suggestion, the number of steps would be shorter - something like
TAKE 7R 2
PUT 7R 1 [0]
PUT 9R 1
I agree now that it is quite a different class from my âBy the wayâ - this directly connects to the objective of finding the least number of steps. I am not sure what my choice would have been if I would have realized this during the construction of this contribution. However, given
- that after your bit more thoughts you are OK,
- that it is not an issue in any of the current cases,
- that I had already given up on making a Rummikub contribution that tested all edges, and
- that I prefer not to change the contribution now it is accepted,
I opt for leaving it as it is.
If you supply a couple more edgy situations that I overlooked, I might need to make a Rummikub 3 instead 
.
1 Like