5 kyu
Snake Collision
93 of 136kodejuice
Loading description...
Arrays
Games
Algorithms
Simulation
Puzzles
View
This comment has been reported as {{ abuseKindText }}.
Show
This comment has been hidden. You can view it now .
This comment can not be viewed.
- |
- Reply
- Edit
- View Solution
- Expand 1 Reply Expand {{ comments?.length }} replies
- Collapse
- Spoiler
- Remove
- Remove comment & replies
- Report
{{ fetchSolutionsError }}
-
-
Your rendered github-flavored markdown will appear here.
-
Label this discussion...
-
No Label
Keep the comment unlabeled if none of the below applies.
-
Issue
Use the issue label when reporting problems with the kata.
Be sure to explain the problem clearly and include the steps to reproduce. -
Suggestion
Use the suggestion label if you have feedback on how this kata can be improved.
-
Question
Use the question label if you have questions and/or need help solving the kata.
Don't forget to mention the language you're using, and mark as having spoiler if you include your solution.
-
No Label
- Cancel
Commenting is not allowed on this discussion
You cannot view this solution
There is no solution to show
Please sign in or sign up to leave a comment.
Quite a classic, nice one.
Even more seriously annoying issues:
steps
, is each move considered a step, are turns included, ..?It seems you don't print the initial state, but final state. So a handful of the above issues are possibly related to that. So confusing. EDIT: no wait, you DO print the initial state. My god, what a horrible kata. This truely is an example how NOT to write a kata.
it is the final state of the grid that is printed; there are no tests with initial snakes not located in
(0, 0), (0, 1), (0, 2)
that's odd, I printed the grid at start and got snakes at all kinds of locations
I have no clue why printing went horribly wrong.
"Initial size of snake would be always 3"
Random test -> size = 5
The recently included test case that verifies food is only consumed once is causing a contradiction with other test cases.
Some tests assume food remains in the field after being eaten so this Kata is no longer solvable.
Example:
moves = '7 D 7 R 3 U 1 L 7 U 6 L 1 U 5 L 6 D 3 L 8 U 6 L 2 U 3 R 1 D 5 R 5 D 4 R 4 U 7 R 2 D 4 R 7 U 8 R 4 D'
The test says ((0, 4), 33) should equal ((6, 10), 21) but this could only be true if the snake ate the same food twice and was long enough to collide with itself.
I've found a few other scenarios like this.
i have run the simulation step-by-step for this test case and the expected answer is correct. the final state is (with head at
H
, going leftwards and hence colliding):Hello, I think there is a anomaly on the test case
ooo$$$$$$$$$$$$$$$$$$ --------------------$ $-------------------$ $-------------------$ $-------------------$ $-------------------$ $-------------------$ $-------------------$ $-------------------$ $-------------------$ $-------------------$ $-------------------$ $$$$$$$$$$$$$$$$$$$$$ 18 D 12 L 20 U 12 R 5
Indeed, the snake can turn around and grow as we have one space on the border, the head is never on the tail. it should be OK. Why to expect ((0, 5), 67) and not ((0, 5), 0) as all moves were successful?
Are we just gonna accept this is a 5kyu kata?
Description asks for head position and N: Number of steps leading up to and including the collision
There is a test case with these moves given: U R L D U R L D
The first move leads to a collision against the top border of the board. However the test expects [[0, 2], 0] rather than [[0, 2], 1]
Am I missing something or is this wrong?
Directions certainly changed but the snake didn't move...
(U doesn't mean the snake moves Up one step)
Snake doesn't move when changing its direction. It seems this information was removed from the description during the rewrite.
I was struggling with this too and then I figured out that when there's no number with the direction is considered as a head turn without movement, so you don't have to count the step.
Thanks guys! appreciate it!
This was my bad for reading the description poorly. I thought that U U U was identical to U 3 - not the case.
This is realy confusing formulation. If UDLR is just head rotation, without movements, than snake can rotate head to his neck and collide himself on next movement.
Random tests only generate 90 degrees rotations.
This looks like an awful lot of work for a 5kyu.
Are you referring to the requirements to solve it? Then I disagree. It can be done in 20-30 LoC. In fact I got smacked over the head because I rated it a 6kyu kata :D
It's a first impression. ;-) I find the 'find your way in a 2D-array' challenges usually quite tedious to code. Not really difficult, per se, but prone to bugs. At least for me.
I know what you mean, but it then becomes all the more important to reduce the problem to it's core issues before assuming any given solution path. This one is absolutely not about path finding at all (the path is part of the input).
Description doesn't say if food can be used multiple times or only once.
Both versions pass the tests (at least in python).
I mentioned this below. There are no tests to see whether food is eaten twice. Logically, food should vanish off the field when consumed. My solution doesn't do this, but it currently doesn't matter. One would have to add a test where a solution that doesn't clear the food after consuming it causes the head to collide with the tail (because it grew when it shouldn't), making it fail.
A test that looked something like this should do it:
While I'm fine changing the description myself, I'm not going anywhere near tests. Someone with more experience can implement this.
What do we return if there is no collision when all moves have been executed?
The description should specify this.
Although the last line mentioning collisions specifically does retrospectively make it sound like you should only return those things when a collision happens. If no collision happens, ignore the last line. Then just return whatever the position of the snake's current head is. Thats how I understood it and what the tests expect.
Are width and height values mixed up in details? Or sample represented column wise?
Thanks. Fixed. Height is indeed 13, width is 21. Don't let the formatting fool you :)
Nice Kata!
May I suggest a small helper function for debugging purposes :
arr is the field array (only '$' and '-') and occ the positions occupied by the snake.
Actually, author had given such functions but while re-writing the description I entirely forgot to mention them. Now, I've to figure out what those functions do(you can see them in preloaded section though), and state them accordingly in the description(but may be tommorow)
Shouldn't figuring out how to debug a problem be part of the challenge? Seeing how essential it is to any programming task, this would provide a learning opportunity for anyone who hasn't done so yet (and in this case it's a rather simple task – printing a bunch of lines)
I sincerely apologize for the very horrible description, this was 3years ago, and i had just started creating katas at that time. I didn't really put in much effort into the correctness of the problem description and test cases, i apologize for that. Thanks @XRFXLP for the fixes done.
I can't imagine how bad the initial description must have been.
Are there any tests that check whether food is consumed twice? Because my code does not even check for that and it passes.
No tests with no moves.
The issue is back.
.
Edit: The current test behaviour doesn't match what was previously expected:
[(1, 14), 19] should equal ((1, 15), 19)
The step count in particular expects the current move that caused the collision to be counted. See the second test in the samples: It collides on the first move, and expects
steps=1
. The description statesThe wording is actually a bit ambiguous, now that I think about it. In any case, I can pass the second test but fail the first sample test as mentioned above.
No tests with no moves.
Now there are tests with no moves. :V
If no collision occurs, tests expect the one-before-last head position instead of the last one.
Fixed(assuming you were talking about python)
The explanations should be rewritten in terms of body segments instead of the snake as a whole where relevant. "Tail" could mean both the last segment of its body, and every segment excluding the first one.
Is this not sufficient:
?
No? "Snake" is an abstraction, while the segments are real, and all the behavior is expressed by those segments - why do you think explaining the behavior using an abstraction is sufficient?
Okay, cool Lemme define the
tail
.Can we have a consistent description, please?
Ah, thanks. That was temporary fix, I'm re-writing the description.
Random tests should include grids of different sizes and various densities of food.
Having random field size doesn't add anything to the task, so is having highly varying amount of food. Not an issue.
I would suggest to make it more clear, that if snake moved into the cell, where the end of its tail was, it is considered collision. Because in some realizations of "snake" game it is considered a valid move.
With each step the snake moves its head to the adjacent cell according to current direction, and then draws its tail from its last position (so after the 1-st step the cell (0,0) becomes empty etc.)
change to
With each step the snake firstly moves its head to the adjacent cell according to current direction, and after that draws its tail from its last position (so after the 1-st step the cell (0,0) becomes empty etc). If snake moves into the cell, where its tail just is, it is considered collision.
P.S. It appears, that FArekkusu has already made issue about that. I will leave this suggestion with an improved description.
Wait, I'm not at all sure what you're talking about here.
Is running into its own tail is not controlled by th statement "colliding into itself"? Tail is a part of body, right?
I'm using the same terminology, as the author. He has written
collide with itself
multiple times, so I just go with it.Okay, but I'm still not sure where the ambiguity lies?
There was a discussion on gitter about that. The ambiguity is in the fact, that if all snake moves at the same time, it's head should not collide with the tail, if it moves in position of tail. But it does. I suggest to explicitly tell that in the description.
Collision occurs on the boundary of 2 cells, not in one particular cell, so this could be interpreted as either "the last valid", or "the new invalid" position of the head.
What's worse, the 2 different collision cases correspond to different interpretations - ideally, this should be made consistent too (at least if kazk decides to throw this kata back into beta).
Physically, sure, but logically the head is never on a boundary, it is in one cell or another; a logical collision happens when the head is in a new cell that was previously occupied (or is outside the boundaries of the field).
That made the distinction clear for me. Not?
The third function parameter should be removed from the initial solution in JavaScript.
Node 12 should be enabled.
New test framework should be used in Python.
It is not specified whether moving to the position of the last segment of the body results in a collision or not.
.
I'm not sure if I should make it a suggestion or an issue, but let it be issue for starters.
According to your suggestion, what should one return as
X
andY
in case of no collision?Coordinates of the snake's head, after the snake has done all the movements.
How?
JS random tests:
ReferenceError: field is not defined at Test.it._
Done.
Careful with the expressions you use:
if you are in cartesian coordinates, y is ascending, and since you talk about the celle(0,0) being the top left corner, the origin of your axes is there. But your "y"s are descending, currently. So just remove the "cartesian" and keep the reamining of the sentence.
This comment has been hidden.
Fixed
there are problems when republishing, currently, you might not be able to validate the change.
no it's not because, since the snake makes a loop, the display is fully useless and one would have to follow each step by hand to MAYBE get the expected solution, which is unlikely in some edge cases because you do not provide the full/correct set of rules. So, yes, it is an issue.
And even provding the full set of rules, what is the point of not giving the expected result? Except the will to annoy the user???
_
not enough fixed tests: you should have at least one of each collision case, one with and one without turn before hitting a border, one with a flip of direction (U 2 D 3) and things like that.
_
@ZED: your ranking is nuts...
...There are no math, algo, performance, specificated knowledge requirement... The only thing to do is simulation, i mean, it could not be tougher than a typical knapsack problem or any other problems requiring carefully thinking :wink:
seriously, That becomes to be boring... Just open your eyes and LOOK at what are 7 kyus. And what about the abstraction needed to descompose the task? Going this way, FMC1 would be 6kyu to you, I guess?
BTW knapsack is NOT 7 kyu. Or we aren't talking about the same thing.
Knapsack is like 6kyu or 5kyu. By
not be tougher than
i mean it is like 6kyu or 7kyu. Okay, this one is better than those 7kyus, changed.LOL!
Seriously!? How many times did we already told you to NOT use
test.expect
unless you provide a useful assertion message...? X-/And that leads to another problem: You tell in the description:
X, Y = coordinates of the cell where a collision ocurred
. But isn't it actually the position of the head right BEFORE the collision, then? If not, there will be an inconsistency between collision on borders and collisions with the snake itself.i used
Test.expect(false)
on purpose, its meant to break the tests and out that error message "Value is not what ...", i printed the field after the moves have been done, isnt that enough for you ?Looks a very interesting one! Though the description is lacking some information:
Note that using different types of returned values is a bad idea. You should change the default return statment to an empty list
Got my answer after seeing your code:
How on earth can the number of turns be zero ???
About the border collisions and the cartesian coordinates, i will update the description
how on earth could you think anybody will know what's in your mind? In some problem of that type, some makes the choice of using a 0 indexing, yes.
Ah, and BTW... You ARE using a 0 indexing... initial position is at turn 0, not turn 1.
Remind me what you just told...?
There are always steps to take in every test case, so the turn can never be zero
Seriously...?
This is useless...
You expect test cases where there are no steps to take ?
That doesnt make any sense at all.
Wouldn't the result always be
-1
??ofc not. You initiate turn value at 0. That's the initial state. You take the first command, you get at turn 1. First possible output, 1. But your initial state is indexed at turn 0. It's in your code... (mine begin at 1 because I do the update after the moves. You do it at the beginning of each turn. Which implies exactly what I just said).
Note: new edge case in the fixed tests: begin with direction facing north, move => fail.
You mean sumtn like
U 4
?yes