In this assignment, you will build general-purpose search algorithms and apply them to solving puzzles. In Part 1 (for everybody), you will be in charge of a "Pacman" agent that needs to find paths through mazes while eating one or more dots or "food pellets." In Part 2 (for four-credit students), you will tackle a simplified Rubik's Cube puzzle. As stated in the beginning of the course, you are free to use any high-level programming language you are comfortable with. This includes (but is not limited to) Java, C++, Python, and MATLAB. The focus of this course is on problem solving, not programming, and the grading will primarily be based on the quality of your solutions and your analysis, as evidenced by your written report. You have the option of working in groups of up to three people. Three-credit students must work with three-credit students and four-credit students must work with four-credit students. To form groups, feel free to use Piazza. Needless to say, working in a group will not necessarily make your life easier, as the overhead of group coordination can easily outweigh the benefits. ContentsPart 1: For everybody1.1 Basic pathfindingConsider the problem of finding the shortest path from a given start state while eating one or more dots or "food pellets." The image at the top of this page illustrates the simple scenario of a single dot, which in this case can be viewed as the unique goal state. The maze layout will be given to you in a simple text format, where '%' stands for walls, 'P' for the starting position, and '.' for the dot(s) (see sample maze file). All step costs are equal to one.Implement the state representation, transition model, and goal test needed for solving the problem in the general case of multiple dots. For the state representation, besides your current position in the maze, is there anything else you need to keep track of? For the goal test, keep in mind that in the case of multiple dots, the Pacman does not necessarily have a unique ending position. Next, implement a unified top-level search routine that can work with all of the following search strategies, as covered in class:
Run each of the four search strategies on the following inputs: For each problem instance and each search algorithm, include the following in your report:
Part 1.2: Search with multiple dotsNow consider the harder problem of finding the shortest path through a maze while hitting multiple dots. Once again, the Pacman is initially at P, but now there is no single goal position. Instead, the goal is achieved whenever the Pacman manages to eat all the dots. Once again, we assume unit step costs.As instructed in Part 1.1, your state representation, goal test, and transition model should already be adapted to deal with this scenario. The next challenge is to solve the following inputs using A* search using an admissible heuristic designed by you: You should be able to handle the tiny search using uninformed BFS -- and in fact, it is a good idea to try that first for debugging purposes, to make sure your representation works with multiple dots. However, to successfully handle all the inputs, it is crucial to come up with a good heuristic. For full credit, your heuristic should be admissible and should permit you to find the solution for the medium search in a reasonable amount of time. In your report, explain the heuristic you chose, and discuss why it is admissible and whether it leads to an optimal solution. For each maze, give the solution cost and the number of nodes expanded. Show your solution by numbering the dots in the order in which you reach them (once you run out of numbers, use lowercase letters, and if you run out of those, uppercase letters). Part 1 extra credit: Suboptimal searchSometimes, even with A* and a good heuristic, finding the optimal path through all the dots is hard. In these cases, we'd still like to find a reasonably good path, quickly. Write a suboptimal search algorithm that will do a good job on this big maze. Your algorithm could either be A* with a non-admissible heuristic, or something different altogether. In your report, discuss your approach and output the solution cost and number of expanded nodes. You don't have to show the solution path unless you want to come up with a nice animation for even more extra credit.Tips
Part 2 (For four-credit students): Rubik's CubeRubik's Cube has been a popular toy for nearly 40 years. In this part of the assignment, you will build a solver for a 2*2*2 "pocket cube," which is shown below. Please read both parts below and plan carefully before starting to code!Part 2.1: Solving the Cube without Rotation InvarianceThe cube has six faces: Top, Bottom, Front, Back, Left, and Right. Any one of its faces can be turned by 90 degrees in either the clockwise (CW) direction or the counterclockwise (CCW) direction. We denote the moves by a single capital letter for the face turned (Top, Bottom, Front, Back, Left, Right) and a prime mark if the face was turned CCW instead of CW. For example, the sequence of movesmeans turning the Top face clockwise followed by turning the Bottom face clockwise and finally turning the Back face counterclockwise. So your implementation should support these 12 types of moves. There are six colors: red, green, blue, orange, yellow, and purple. We represent states or configurations of the cube by listing the colors in each of the four positions of each of the six faces. The cube is considered solved when each face has only one color and this configuration is reachable from the initial configuration. The goal state used in this part of the assignment is as follows: The face with 4 'r' is Left, the face with 4 'b' is Top, the face with 4 'g' is Right, the face with 4 'o' is Front, the face with 4 'y' is Bottom, and the face with 4 'p' is Back. The above configuration is the unique goal state for this part, i.e. for the cube to be considered solved the faces should have the colors as shown in the above diagram. No other state is to be considered as the goal even if the cube appears to be solved, i.e. has the same colors within each face. More generally, for now, we DO NOT consider configurations to be the same if the entire cube can be rotated in space to go from one configuration to the other. Here is a sample input in the same format as the goal state above: Note that there are 4 spaces in the input files starting from the third line right up to the last line. Parse the input carefully according to this format specification. The goal of this part is to solve the following three inputs with A* search: For the heuristic, consider the number of misplaced cubes. Is this heuristic admissible? Should it be multiplied or divided by a factor to make it admissible? For each input, report the sequence of moves needed to reach the goal configuration using the move notation specified above. Also report the number of nodes expanded by your A* algorithm to find this solution, and the running time. Tips
Part 2.2: Adding Rotation InvarianceIf we consider the cube in 3D space, any two configurations that are separeted by a global 3D rotation are actually equivalent. In particular, we have 24 configurations that look different according to their 2D layout representation, but are actually equivalent in 3D (we can fix the front face in 6 ways and rotate the 4 sides attached to the front face in either clockwise or counter-clockwise direction 4 times). In this part, you need to modify your goal test, repeated state detection, and heuristic to take these equivalences into account. Describe the modifications in your report. With these modifications, you should be able to handle more complicated puzzles requiring longer solution paths. Run your modified A* search on the following inputs:For each input, as before, give the solution path, the number of nodes expanded, and the running time. For the first input, discuss the differences between the solutions and the behavior of the two versions of your algorithm. If you run into running time or memory problems on any of the inputs, feel free to set a cutoff on the search depth or number of nodes expanded, and specify in your report at which point you had to terminate the search. Part 2 Extra Credit
Report ChecklistYour report should briefly describe your implemented solution and fully answer the questions for every part of the assignment. Your description should focus on the most "interesting" aspects of your solution, i.e., any non-obvious implementation choices and parameter settings, and what you have found to be especially important for getting good performance. Feel free to include pseudocode or figures if they are needed to clarify your approach. Your report should be self-contained and it should (ideally) make it possible for us to understand your solution without having to run your source code. For full credit, in addition to the algorithm descriptions, your report should include the following.Part 1 (for everybody):
Part 2 (for four-credit students):
Extra credit:
Statement of individual contribution:
Submission InstructionsBy the submission deadline, one designated person from the group will need to upload the following to Compass2g:
Compass2g upload instructions:
Late policy: For every day that your assignment is late, your score gets multiplied by 0.75. The penalty gets saturated after four days, that is, you can still get up to about 32% of the original points by turning in the assignment at all. If you have a compelling reason for not being able to submit the assignment on time and would like to make a special arrangement, you must send me email at least a week before the due date (any genuine emergency situations will be handled on an individual basis). Be sure to also refer to course policies on academic integrity, etc. |