There are four plain English algorithms for the Towers of Hanoi Puzzle available on Wikipedia, but when I was first solving the puzzle, I came up with an algorithm that is different from any of the solutions I have seen.
Wikipedia algorithms:
Iterative solution
Simpler statement of iterative solution
Equivalent iterative solution
Recursive solution
Of course the results of the algorithms are the same, and they are really just different ways of thinking about the same thing, but I am talking about plain English ways of describing the process.
My process goes like this:
Never move same tile twice in a row(obviously)
Prioritize moving right
When moving right, move to the closest pole that can be legally moved to.
When moving left, move to the farthest pole that can be legally moved to.
..
These rules differ from other descriptions of the algorithm in that:
The initial stack can be placed on any of the 3 pillars and still work without any adjustment to the rules needed.(Unlike solutions 2 and 3 and 4)
You don't have to number the disks(Unlike solutions 1 and 3 and 4)
I have tested this programmatically, and it always solved the puzzle in (2^n)-1 moves where n is the number of rings.
It seems to me that my description really is different from the other plain English descriptions I have found. Has any one seen this description before? If so, please show reference.
I think your description is pretty much the same as Iterative Solution. Just imagine the posts arranged around a circle or a triangle, mod 3 style. Your instructions and Wikipedia's instructions translate to the same thing in that way of viewing things.
This solution is a unidirectional version of the first iterative solution.
The difference between the unidirectional solution and the mono-directional version is the unidirectional solution doesn't specify an end position.
A simple solution for the toy puzzle: Alternate moves between the
smallest piece and a non-smallest piece. When moving the smallest
piece, always move it to the next position in the same direction (to
the right if the starting number of pieces is even, to the left if the
starting number of pieces is odd). If there is no tower position in
the chosen direction, move the piece to the opposite end, but then
continue to move in the correct direction. For example, if you started
with three pieces, you would move the smallest piece to the opposite
end, then continue in the left direction after that. When the turn is
to move the non-smallest piece, there is only one legal move. Doing
this will complete the puzzle in the fewest number of moves.
This description of the mono-directional version can be changed to be unidirectional if direction choices of direction are replaced with the rules from the unidirectional solution revolving around prioritizing moving right.
Related
I've tried searching for a while, but haven't come across a solution, so figured I would ask my own.
Consider an MxM 2D grid of holes, and a set of N balls which are randomly placed in the grid. You are given some final configuration of the N balls in the grid, and your goal is to move the balls in the grid to achieve this final configuration in the shortest time possible.
The only move you are allowed to make is to move any contiguous subsection of the grid (on either a row or column) by one space. That sounds a bit confusing; basically you can select any set of points in a straight line in the grid, and shift all the balls in that subsection by one spot to the left or right if it is a row, or one spot up or down if it is a hole. If that is confusing, it's fine to consider the alternate problem where the only move you can make is to move a single ball to any adjacent spot. The caveat is that two balls can never overlap.
Ultimately this problem basically boils down to a version of the classic sliding tile puzzle, with two key differences: 1) there can be an arbitrary number of holes, and 2) we don't a priori know the numbering of the tiles - we don't care which balls end up in the final holes, we just want to final holes to be filled after it is all said and done.
I'm looking for suggestions about how to go about adapting classic sliding puzzle solutions to these two constraints. The arbitrary number of holes is likely pretty easy to implement efficiently, but the fact that we don't know which balls are destined to go in which holes at the start is throwing me for a loop. Any advice (or implementations of similar problems) would be greatly appreciated.
If I understood well:
all the balls are equal and cannot be distinguished - they can occupy any position on the grid, the starting state is a random configuration of balls and holes on the grid.
there are nxn = balls + holes = number of cells in the grid
your target is to reach a given configuration.
It seems a rather trivial problem, so maybe I missed some constraints. If this is indeed the problem, solving it can be approached like this:
Consider that you move the holes, not the balls.
conduct a search between each hole and each hole position in the target configuration.
Minimize the number of steps to walk the holes to their closest target. (maybe with a BFS if it is needed) - That is to say that you can use this measure as a heuristic to order the moves in a flavor of A* maybe. I think for a 50x50 grid, the search will be very fast, because your heuristic is extremely precise and nearly costless to calculate.
Solving the problem where you can move a hole along multiple positions on a line, or a file is not much more complicated; you can solve it by adding to the possible moves/next steps in your queue.
I am trying to solve a Variation of the Towers of Hanoi. In this case I have two towers, same height and the disks have the same sizes. I can stack disks onto each other as long as they are the same size or smaller. The color does not factor in to the stacking capabilities.
I have three pegs and two towers and the task is to swap both towers.
My initial approach is to build one tower with alternating colors and then going backwards with just a different peg to move to.
I am just thinking that this is not the most elegant solution. Is there a better way to do this?
Update:
I thought I was pretty close to figuring this out, but I wasn't. I have all the moves (for n=3) on paper and it looks pretty similar to the original algorithm just that lots of moves are done twice. Unfortunately I am not able to put this into a recursive algorithm. This is pretty frustrating. Does someone have an idea?
There is a website that addresses various versions of the Tower of Hanoi.
Also, if you want to do this recursively, you don't actually need to know what is going to happen. You can just try all available moves recursively until you reach the solution.
I have played a little flash game recently called Just A Trim Please and really liked the whole concept.
The basic objective of the game is to mow the whole lawn by going over each square once. Your lawn mower starts on a tile and from there you can move in all directions (except where there are walls blocking you). If you run on the grass tiles more than once it will deteriorate and you will lose the level. You can only move left, right, up, or down.
However, as you finish the game, more tiles get added:
A tile you can only mow once (grass).
A tile you can run over twice before deteriorating it (taller grass).
A tiie you can go over as much as you want (concrete).
A tile you can't go over (a wall).
If you don't get what I mean, go play the game and you'll understand.
I managed to code a brute-force algorithm that can solve puzzles with only the first kind of tile (which is basically a variation of the Knight's Tour problem). However, this is not optimal and only works for puzzles with tiles that can only be ran on once. I'm completely lost as to how I'd deal with the extra tiles.
Given a starting point and a tile map, is there a way or an algorithm to find the path that will solve the level (if it can be solved)? I don't care about efficiency, this is just a question I had in mind. I'm curious as to how you'd have to go to solve it.
I'm not looking for code, just guidelines or if possible a plain text explanation of the procedure. If you do have pseudocode however, then please do share! :)
(Also, I'm not entirely sure if this has to do with path-finding, but that's my best guess at it.)
The problem is finite so, sure, there is an algorithm.
A non-deterministic algorithm can solve the problem easily by guessing the correct moves and then verifying that they work. This algorithm can be determinized by using for example backtracking search.
If you want to reduce the extra tiles (taller grass and concrete) to standard grass, you can go about it like this:
Every continuous block of concrete is first reduced into a single graph vertex, and then the vertex is removed, because the concrete block areas are actually just a way to move around to reach other tiles.
Every taller grass tile is replaced with two vertices that are connected to the original neighbors, but not to each other.
Example: G = grass, T = tall grass, C = concrete
G G T
G C T
C C G
Consider it as a graph:
Now transform the concrete blocks away. First shrink them to one (as they're all connected):
Then remove the vertex, connecting "through" it:
Then expand the tall grass tiles, connecting the copies to the same nodes as the originals.
Then replace T, T' with G. You have now a graph that is no longer rectangular grid but it only contains grass nodes.
The transformed problem can be solved if and only if the original one can be solved, and you can transform a solution of the transformed problem into a solution of the original one.
There is a DP approach for the travelling salesman.
Perhaps you could modify it (recalculating as more pieces are added).
For a long piece of grass, you could perhaps split it into two nodes since you must visit it twice. Then reconnect the two nodes to the nodes around it.
I've been thinking about an algorithm for solving small puzzles. I found different algortihms on the internet and on stackoverflow but they do not meet my needs in some points:
My puzzle pieces are in one color, there is no image/pattern/... on them
Every edge of a part can be one of 8 options, similar to them on the picture (you can describe the parts as ABCD, cdab, cBBb, ADcb for example); there are no more complicated structures or anything like that
The puzzles I want to solve are not to big, there are no ones bigger than 8x8
The corner/egde pieces have no specific edges, the result will just not be a clean rectangle
Not all my puzzles are solvable
The parts can be rotated but not turned
Every puzzle part is unique
Example puzzle parts
So my starting point would be just brute force - lay piece 0 down in the (0,0) position, then start trying any of the remaining pieces in (0,1) until one fits, then move on to (0,2), etc. At any step if there are no pieces that fit in that space, take out the previously fit piece and try to find a new fit for that square.
I can't prove it, but I suspect that filling in pieces such that you are more likely to be evaluating a piece with 2 constraints (that is, instead of doing larger squares, 2x2, 3x3, 4x4, moving out) will terminate faster than just doing rows.
It reminds me of those 3x3 puzzles where you have square pieces with heads and tails of animals. One optimization there is to count up the mismatch between pairs - if you you have a lot more A than you have a then you know that A will tend to be located at the edges of the puzzle, but in an 8x8 puzzle you have a lot less edge to interior ratio so that difference isn't as likely to be useful, nor do I have a good idea for integrating it into an algorithm.
(Edit) Thinking about it more, I think the first thing that counting would get you is an early out if no solution exists. An NxN grid has 2*N*(N-1) interior matches that must be satisfied. If min(A,a) + min(B,b) + min(C,c) + min(D,d) < 2*N*(N-1) you know no solution exists.
(Edit 2) had abs() where I meant to have min(). Ooops.
This is a variation to the original Towers of Hanoi problem. The same rules apply but instead of having just one stack of n disks there are two. One stack of red disks on the left pole and another stack of purple disks on the right. The final configuration should be the purple on the left and red on the right. There are a total of 3 poles.
I'm having trouble understanding/creating the pseudocode for an algorithm that solves this problem. Please help.
The problem as you have presented it is not generally solvable. According to wikipedia, the most trivial multi-stack game has two stacks and four poles, and in general there are twice as many poles/pegs as stacks.
In the 2 stacks x 3 poles case you can see fairly quickly that for n > 1 you can't get very far. The smallest two discs occupy the top of two or one poles, and you can therefore never swap the second-smallest two discs since that always requires one temporary pole.
Since this is homework so giving you the answer would be wrong, I would suggest that you graphically solve the Towers of Hanoi problem.
Then, add in the modification, and see how your original solution works with the new change.
You should see where the original may fail, but it would be easier to make the modification while looking at it graphically.
If you pick a language that is easy to do graphic solutions then you can do this very fast.
For example, GWT may be a good choice, or Rails, though TCL/TK would also be easy.