Fair Attraction Problem
What I've Tried
I tried thinking about the switches as bits of a bit string. Basically, no matter the state, I need to get them all to zero. And since this question is in a chapter about decrease-and-conquer I tried to solve for n=1. But, I can't even come up with a brute force solution to ensure that one switch is off.
If you have any ideas or hints, please help, thank you.
Since the only feedback we get is when we're in the goal state, the problem is to explore all possible states as efficiently as possible. The relevant mathematical object is called a Gray code. Since you're looking for a recursive construction, the algorithm is:
If there are no switches, then there's one state, and we're in it.
Otherwise, pick a switch. Recursively explore all configurations of the other switches. Flip the held-out switch and then recursively explore the others again.
Related
I'm trying to solve the Sokoban puzzle in Prolog using a depth-first-search algorithm, but I cannot manage to search the solution tree in depth. I'm able to explore only the first level.
All the sources are at Github (links to revision when the question was asked) so feel free to explore and test them. I divided the rules into several files:
board.pl: contains rules related to the board: directions, neighbourhoods,...
game.pl: this file states the rules about movements, valid positions,...
level1.pl: defines the board, position of the boxes and solution squares for a sample game.
sokoban.pl: tries to implement dfs :(
I know I need to go deeper when a new state is created instead of checking if it is the final state and backtracking... I need to continue moving, it is impossible to reach the final state with only one movement.
Any help/advice will be highly appreciated, I've been playing around without improvements.
Thanks!
PS.- ¡Ah! I'm working with SWI-Prolog, just in case it makes some difference
PS.- I'm really newbie to Prolog, and maybe I'm facing an obvious mistake, but this is the reason I'm asking here.
This is easy to fix: In sokoban.pl, predicate solve_problem/2, you are limiting the solution to lists of a single element in the goal:
solve_dfs(Problem, Initial, [Initial], [Solution])
Instead, you probably mean:
solve_dfs(Problem, Initial, [Initial], Solution)
because a solution can consist of many moves.
In fact, an even better search strategy is often iterative deepening, which you get with:
length(Solution, _),
solve_dfs(Problem, Initial, [Initial], Solution)
Iterative deepening is a complete search strategy and an optimal strategy under quite general assumptions.
Other than that, I recommend you cut down the significant number of impure I/O calls in your program. There are just too many predicates where you write something on the screen.
Instead, focus on a clear declarative description, and cleanly separate the output from a description of what a solution looks like. In fact, let the toplevel do the printing for you: Describe what a solution looks like (you are already doing this), and let the toplevel display the solution as variable bindings. Also, think declaratively, and use better names like dfs_moves/4, problem_solution/2 instead of solve_dfs/4, solve_problem/2 etc.
DCGs may also help you in some places of your code to more conveniently describe lists.
+1 for tackling a nice and challenging search problem with Prolog!
I'm having trouble writing the pathfinding routine for the AI in a simple Elite-esque game I'm writing.
The world in this game is a handful of "systems" connected by "wormholes", and a ship can jump from the system it's in to any system it's linked to once per turn. The AI is limited to only knowing things that it should know; it doesn't know what links come from a system it hasn't been to (though it can work it out from the systems it has seen, since links are two-way). Other parts of the AI decide which system the ship needs to get to based on what goods it has in its inventory and how much it remembers things being worth on systems it has passed through.
The problem is, I don't know how to approach the problem of finding a path to the target system. I can't use A*; there's no way to determine the 'distance' to another system without pathing to it. I also need this algorithm to be efficient, since it'll need to run about 100 times every time the player takes his turn.
Does anyone know of a suitable algorithm?
I ended up implementing a bidirectional, greedy version of breadth-first search, which suits the purpose well enough. To put it simply, I just had the program look through each node its starting node connected through, then each node those nodes connected to, then each node those connected to... until the destination node was found.
Normally one would build a list of appropriate paths and pick the shortest one, but I tried a different method; I had the program run two searches in parallel, one from the starting point, and one from the end point. When the 'from' search found the last node of the 'to' search, the path was considered found.
It then optimizes the path by checking if each node on the path connects to a node further up in the path, and deleting each node in between them.
Whether or not this funky algorithm is actually any better than a straight BFS remains to be seen.
When it comess to unknown environments, I usually use an evolutionary algorithm approach. It doesn't guarantee that you'll find the best solution in the small timeframe you have, but is a way to approach such a problem.
Have a look at Partially Observable Markov Decision Problems (POMDP). You should be able to express your problem with this model.
Then you can use an algorithm that solves these problems to try to find a good solution. Note that solving POMDPs is usually very expensive and you probably have to resort to approximate methods.
Easiest way to cheat this would be o go through, or at least attempt to access as many systems as possible, then implement the distance heuristic as the sum of all the systems you've been to.
Alternatively, and way cooler:
I've implemented something similar using ACO (Ant colony optimization) and worked pretty well combined with PSO(particle swarm optimization), however, the additional constraints your system is imposing means that you'll have to spend a few (at least one) sessions figuring out the environment layout, and if it's dynamic... well... though.
The good thing is that this algorithm completely bypasses the need for heuristic generation which is what you need since you are flying blind. Be advised though, that this is a bad idea if your search space (number of runs) is small. (100 may be acceptable, but 10 or 5 ... not so much).
This scales up quite nicely when dealing with large numbers of nodes (systems) and it bypasses the heuristic distance computational need for every node-to-node relationship, thereby making it more efficient.
Good luck.
I've implemented the natural actor-critic RL algorithm on a simple grid world with four possible actions (up,down,left,right), and I've noticed that in some cases it tends to get stuck oscillating between up-down or left-right.
Now, in this domain up-down and left-right are opposites and feel that learning might be improved if I were somehow able to make the agent aware of this fact. I was thinking of simply adding a step after the action activations are calculated (e.g. subtracting the left activation from the right activation and vice versa). However, I'm afraid of this causing convergence issues in the general case.
It seems as so adding constraints would be a common desire in the field, so I was wondering if anyone knows of a standard method I should be using for this purpose. And if not, then whether my ad-hoc approach seems reasonable.
Thanks in advance!
I'd stay away from using heuristics in the selection of actions, if at all possible. If you want to add heuristics to your training, I'd do it in the calculation of the reward function. That way the agent will learn and embody the heuristic as a part of the value function it is approximating.
About the oscillation behavior, do you allow for the action of no movement (i.e. stay in the same location)?
Finally, I wouldn't worry too much about violating the general case and convergence guarantees. They are merely guidelines when doing applied work.
I've implemented the algorithms marked as the correct answer in this question: What to use for flow free-like game random level creation?
However, using that method will create boards that may have multiple solutions. I was wondering if there is any simple restrictions or modification that can be made to the algorithm to make sure that there is only one possible solution?
Creating unique Numberlink/Flow Free is very difficult. If you look at my algorithm proposal in the mentioned thread, you'll find an algorithm that lets you create puzzles with the necessary condition that solutions must not have a 2x2 square of the same color. The discussion at http://forum.ukpuzzles.org/viewtopic.php?f=3&t=41, however, shows that this is insufficient, since there are also many non-trivial non-unique puzzles.
From my looking into this problem, it seems the only way to solve this problem is to have a separate algorithm for testing uniqueness, and discarding bad instances. One solver that's made precisely for uniqueness testing algorithm is Imo's solver.
Another option is to use multiple different solvers and check that they come up with the same solution.
I think you should implement the solver, which finds all the solutions for some level. The simplest way is backtracking.
When you have many levels, take one by one and look for solutions. As soon as you find the second solution for some level, throw that level away.
I'm using C#, but in the future I might need to use it on other languages.
Many games have such puzzles. There is a group of wires (there are 2 types of wires: straight and curved.), there is a place from where a signal comes and there is a place from where the signal must leave. But the arrangement of the wires doesn't allow that to happen. You must turn some of the wires in order to create a path for the signal.
Yeah, I'm trying to find the continent America again, in order not to try finding it more than once in the future.
Somewhere in the future I will also try the same thing but this time with wires that split the signal to 2 or 3 signals.
Problem is that I can't think of an algorithm that I can imagine how to turn it into a code. I have been thinking for some time and I can't think of anything good.
So, can you help me? I will be able to understand the algorithm as "what does the program has to do", but I basically need help with understanding the algorithm as "how to write the code".
Thanks!
Take a look at some maze generation algorithms -- they do the same thing you're looking for, and as such are what you'll need to create the grid. Pick a simple 'cell-carver' from the ones I linked to; randomly rotate all of the wire-pieces, et voilà!
A comment on your question notes that turning an algorithm into code involves breaking it down bit by bit -- so that's what we'll do:
You'd start with a grid of potential wire locations (probably 2D, but a 3D game would be amazing).
To produce a solvable level, you could do a couple things -- produce a level, and see if it is solvable (bad), or produce a solved level, then "unsolve" it (better). As I alluded to above, producing a solved level involves algorithms very similar to maze generation -- a solved level would have many traversable "paths", just like a maze. Unsolving the level would just loop through all wire pieces, and rotate them a bit.
But what of maze generation? The resource I linked to contains some algorithms that would be perfect for your use -- a simple randomized DFS should be plenty for your needs.
You'll note that I covered the general case involving branching wires -- as it is, excluding branching means you have to do more coding, to "prune" branches intelligently -- that is, backtracking when your one true path gets stuck, say in a corner, due to the random movement probably necessary to make an interesting level.
You should also note that a solution for such a game would, if I understood correctly, require use of all given wire (I know some games like this). Otherwise, the game would probably be a lot simpler to play given the above generation tactics.
The Union-Find algorithms (that answer my problem) are explained in this PDF file: http://www.cs.princeton.edu/~rs/AlgsDS07/01UnionFind.pdf
I don't think I would have ever thought of this algorithm, let alone making it fast.