CPSC 225 Intermediate Programming Spring 2025

Lab 7: Java Collections

Due: Thu Apr 10 at the start of lab

Introduction

The purpose of this lab is to practice working with many of the Java Collections classes (as well as iterators and comparators). You'll also get to see some applications of the different collections as they are employed to solve a tricky problem: how to find your way out of a maze.

About Due Dates

Labs are due at the start of lab on the date listed. It's fine to hand in your lab right at the start of lab, but the lab period is for starting on the new lab, not finishing the previous one.

To be eligible for revise-and-resubmit, you must turn in something by the due date. Late work and extensions are generally not accepted/granted; see the posted late policy for more information.

About Collaboration and Getting Help

You may work with a partner if you wish. Both partners must actively contribute to the solution! You only need one handin for the group — be sure to put both teammates' names in every file.

Otherwise you may get help but you may not use other resources (friends, neighbors, websites, ChatGPT, etc) to produce answers. See the posted policy on academic integrity for more information.

Handin

To hand in your work:

Preliminaries

Maze Solving

You are lost in a maze of twisty little passages, all alike. To make matters worse, your lamp is going dim so you'd better find your way out quickly or you'll be left in the dark. And if you're left in the dark, well, it's very likely that you'll fall into a pit soon after, and then it will all be over.

So, you need to find your way out of the maze as quickly as possible. What to do?

You could wander around randomly, hoping to stumble on the exit before you stumble on a pit. You might get lucky...but you might not. A better solution is some type of systematic exploration where you'll eventually visit every room of the maze — that way, you're guaranteed to find an exit (if one exists). Of course, there is still the risk that it'll take too long and your lamp will go out, but at least you know you won't be wandering around in circles.

Let's consider three kinds of rooms in the maze:

At the beginning, there is exactly one discovered room (the start, which you can see through the maze entrance doorway) and no explored rooms. (Everything else is in the "everything else" category.) So, go through the maze entrance doorway and check the start — is it the exit? If so, that was easy! If not, then peer through the doorways leaving the start and make a note of the rooms that you see. The start becomes "explored" (you now know whether or not it is the exit), and the rooms that you see through doorways are "discovered". Repeat the process with one of the discovered rooms (crossing it off the list), continuing until the exit is found or you run out of discovered rooms (meaning there is no way out). This process can be summarized in pseudocode as follows:

initialize the collection of discovered rooms to contain just the start
while there are more discovered rooms in the collection
  get (and remove) a room from the collection of discovered rooms
  if the room has not already been marked as explored
    mark it as explored
    if it is the exit, you're free (exit the loop)
    otherwise
      for each adjacent room
        if the adjacent room has not been marked as explored or discovered
          mark it as discovered
          add it to the collection of discovered rooms

Provided Code and Files

You've been provided with most of the code needed to have a working maze solver program, including a GUI to show the solving process. The classes you will need to work with are the following:

For Maze and MazePos, look at the public method headers (and comments) in those classes to figure out how to use them. You can ignore the method bodies and private instance variables, though you are welcome to check them out if you are curious about how things work.

You've also been provided with six mazes (maze1.txt, maze2.txt, etc) that you can use for testing the maze solver.

Running the Program

Run MazeSolverMain. You will be prompted for a maze file — enter the name of one of the six maze files (maze1.txt, etc). (If these files are in the top-level directory of your project as directed in the Setup section, you can just enter a filename like maze1.txt)

At first the program will bring up a single window labelled "SolverStack" which displays a maze; when the lab is complete, you'll get three windows labelled "SolverStack", "SolverQueue", and "SolverPQ". (The windows will likely be on top of each other when the program starts up; just move them aside as needed.) Click in a particular window to solve the maze using the indicated solver. (Note that as provided you'll be able to see the maze but nothing will happen when you click — you'll have to finish at least exercise #1 first.)

Exercises

Setup

Exercise #1 — Depth-First Search

The provided SolverStack implements the maze-solving algorithm given above — your task is just to add the parts that deal with collections of things (in this case, rooms of the maze):

At this point you should be able to run the program and see the maze being solved, though the program will crash with a NullPointerException when the goal is found and you won't see the solution path from the start to the goal displayed. That will be taken care of next...

Tips:

Exercise #2 — Solution Path

The maze solving algorithm discussed above tells you that the goal is reachable from the start — that is, that it is possible to get there — but not the route to follow to get to the goal. To be able to construct the actual solution path, an additional piece of information should be stored for each room: where it was discovered from (i.e. the room that you were exploring when the new room was added to the collection of discovered rooms). With this information you can find the solution path once you get to the goal by following the "discovered from" information from the goal back to the start:

  start with the current room being the goal
  while there is still a current room
    add the current room to the path
    update the current room to be the room the current room was discovered from

Note that this generates the solution path in reverse order — from the goal back to the start — so the order of the rooms will need to be reversed in order to find the solution from start to goal.

The "discovered from" information associates the "discovered from" room with each room — this is an associative array application, so it will be a Map with both key and value being rooms (MazePos). For a given room (key), the value is the room it was discovered from.

You should now be able to run the program and see both the maze being solved and the final solution path at the end.

Exercise #3 — Breadth-First Search

A stack is only one kind of container for the discovered rooms — what if a different data structure is used?

Run the program — you should now get two windows (probably on top of each other — move one out of the way). Click in each window to start its solver, and observe how a simple change of the data structure for the discovered rooms — and thus the order in which discovered rooms are explored — changes the solver's behavior. (Note that some statistics about the solver are printed to the console in addition to what is displayed in the GUI.)

Exercise #4 — Best-First Search

Both the stack- and queue-based solvers will get you out of the maze eventually, but you need to get out of the maze quickly. With that goal in mind, you try the strategy of always moving closer to the goal if possible. This means picking the discovered room closest to the goal, which is a task for a PriorityQueue.

However, in order to use a PriorityQueue, it needs to know how to order its contents. There are two possibilities for this: the elements contained have a natural ordering and know how to order themselves, or a separate thing (a Comparator) is defined that specifies how to order things and the PriorityQueue is told to use that. In this case, it's not clear what a natural ordering of MazePos would be — and even if there was such a thing, it probably wouldn't be ordering them based on how far they are from the goal in some particular maze. So the second approach is used here.

But how to compute the distance between a maze position and the goal? Since this maze is laid out on a grid, we'll use a distance measure called the Manhattan distance rather than the straight-line distance between two rooms. The name "Manhattan distance" comes from the borough of Manhattan in New York City — Manhattan is laid out on a grid, and if you are walking between two locations, the distance you walk is the total length of the east-west blocks plus the total length of the north-south blocks because you can't walk diagonally (there are buildings in the way). For the maze, the Manhattan distance between two positions is the absolute difference in row position plus the absolute difference in column position of the two maze positions.

The provided ManhattanDistComparator defines a Comparator for two MazePos objects based on how close they are to the goal, using the Manhattan distance as the measure of distance.

Run the program — you should now get three windows (probably on top of each other — move them out of the way). Click in each window to start its solver, and observe how a simple change of the data structure for the discovered rooms — and thus the order in which discovered rooms are explored — changes the solver's behavior. (Note that some statistics about the solver are printed to the console in addition to what is displayed in the GUI.)

(Optional) If You Have Time

(This isn't required or graded, but is good to think about if you have extra time.)

last updated: --Thu Apr 3 05:21:36 EDT 2025--
page owned by: bridgeman@hws.edu