Skip to content
Skilled.dev

Free lesson walkthrough · Go

Maze reachability in Go: memoized down/right search

Memoize directed maze reachability while keeping unknown distinct from false. Follow the Go implementation, its correctness argument, worked example, complexity, and boundary tests.

4 min read · Worked code, edge cases, and complexity

Determine whether a robot can reach any exit from the upper-left cell of a rectangular room. Open cells contain 0, blocked cells contain 1, and exits contain 2. The robot can move only down or right. It does not move up or left, so this is a directed reachability problem rather than a general four-direction maze search.

Define the state as a cell

Let the answer for (row, column) mean whether an exit is reachable starting there. A position outside the room is false, an exit is true, and a blocked cell is false. An open cell succeeds if either the cell below it or the cell to its right succeeds.

The same cell can be reached by several paths. Without memoization, the recursion repeatedly solves identical suffix regions and can grow exponentially. Store each completed Boolean answer in a memo table. Its entries need three states: unknown, known false, and known true. Treating false as unknown would repeat all unsuccessful searches.

Trace a shared dead end

Consider [[0, 0, 1], [0, 0, 1], [1, 0, 2]]. From the start, moving down or right can eventually reach the center cell. From there the downward route reaches the bottom-middle cell and then the exit. The right neighbor is blocked. Memoizing the center's true result lets a later path reuse it immediately.

Now replace the bottom-middle cell with a wall. The center becomes false. Caching that false is just as useful as caching a success: both incoming paths can stop without exploring the same blocked suffix again. The memo describes reachability from a cell, independent of the path used to arrive there.

Explain why no visiting marker is needed

Every recursive move increases row or column. A path can never return to an earlier cell, so the dependency graph has no cycle. Each state depends only on states farther down or right, and completed answers can be reused safely. General four-direction movement would require a cycle-aware visited policy instead of this argument.

The recurrence checks exactly the legal next moves. If either next state reaches an exit, prefixing the current open cell gives a valid path. If both fail, every legal continuation fails. The out-of-bounds, blocked, and exit base cases complete the correctness argument.

Read the table's absence representation

Java can use boxed Boolean entries so null means unknown. Other languages use optional Booleans, a numeric sentinel, or a map that distinguishes an absent key from a stored false value. The distinction must survive lookup and comparison. A truthiness check alone often collapses unknown and false.

Each of r × c cells has its result computed at most once, with constant work per transition. Time and memo storage are O(r × c). Recursive depth is O(r + c) because a path advances only down and right. The room itself need not be modified. A bottom-up table can remove recursion by processing dependencies from the bottom-right toward the top-left.

Test the movement rule

Use an exit at the start, a blocked start, no exit, a single row, a single column, and a room with several routes to one suffix. Include an arrangement whose only geometric route would require moving left or up; it must fail under this contract. An empty room has no starting cell and returns false.

For an independent oracle, propagate reachable open cells forward from the start and report whether any reachable cell is an exit. This evaluates the directed graph in the opposite direction from the recursive suffix question. A follow-up can count paths, which changes Boolean OR into addition and requires a numeric overflow policy for large rooms.

Go implementation

The memo uses integer states to distinguish unknown from completed answers. That representation avoids conflating a false result with a missing state.

The course uses the function name and concrete slice or pointer types shown here. A slice describes shared backing storage, so reslicing or passing it to a helper does not automatically copy its elements. A nil pointer is distinct from an empty slice. Keep the course's expected result shape and provide explicit copies if an adaptation must preserve mutable input.

const (
	open    = 0
	blocked = 1
	exit    = 2
)

// What the memo knows about the paths from a node
const (
	notChecked = iota
	reachesExit
	deadEnd
)

func hasExitPath(roomMatrix [][]int) bool {
	// Return false if the matrix is invalid
	if len(roomMatrix) == 0 || len(roomMatrix[0]) == 0 {
		return false
	}

	// Init our memoize matrix, where no node has been checked yet
	memoizedPathValidity := make([][]int, len(roomMatrix))
	for row := range memoizedPathValidity {
		memoizedPathValidity[row] = make([]int, len(roomMatrix[0]))
	}

	// Recursively walk through the room to check if there is a valid path
	isValidPath := walkThroughRoom(roomMatrix, 0, 0, memoizedPathValidity)

	return isValidPath
}

// Recursive helper function
func walkThroughRoom(roomMatrix [][]int, row int, col int, memo [][]int) bool {
	// Base case 1: Outside of room, so there can't be a path through this
	isOutsideRoom := row > len(roomMatrix)-1 || col > len(roomMatrix[0])-1
	if isOutsideRoom {
		return false
	}

	// Base case 2: A path successfully reached the end, so propagate this upward
	isOnValidPath := memo[row][col] == reachesExit
	isExitNode := roomMatrix[row][col] == exit
	if isOnValidPath || isExitNode {
		// Set the current node as reaching the exit as well
		memo[row][col] = reachesExit
		return true
	}

	// Base case 3: We reached a blocking node
	isOnInvalidPath := memo[row][col] == deadEnd
	isBlockingNode := roomMatrix[row][col] == blocked
	if isOnInvalidPath || isBlockingNode {
		memo[row][col] = deadEnd
		return false
	}

	// Recursive case: move down and right
	downResult := walkThroughRoom(roomMatrix, row+1, col, memo)
	rightResult := walkThroughRoom(roomMatrix, row, col+1, memo)

	if !downResult && !rightResult {
		// If both this node's right and down are false, we memoize this as a dead end
		memo[row][col] = deadEnd
	} else {
		// If either of the paths are true, this node reaches the exit too
		memo[row][col] = reachesExit
	}

	// Returns true if either is successful
	return downResult || rightResult
}

Practice this implementation

Open Robot Maze to run the implementation against the course tests, then change one boundary condition and explain the first failing case. The editor supplies the starter signature and any node types or helper APIs used above. Copy the implementation into that environment; the snippet is the solution body, without the input parser or test driver. Your saved progress belongs to the original lesson.

For more Go conventions and practice problems, use the Go interview guide.

Try the exercise

Write your own implementation in the course editor. This walkthrough belongs to the same lesson; your course progress stays with that exercise. Exercise access follows the course’s access settings.