2.2.2. Row by Row Computation

So, let us ask ourselves the following question. How do I get to a point (i,j) on the grid? So, I claim, that given our structure, which is, that we can go right or we can go up, there are only two ways I can come here. I can either come right from the neighbor on my left. So, from (i,j minus 1) I can make one step right and come to (i,j) or from (i minus 1, j), I can go up once there. So, if I have any paths, which starts at (0,0), right, any path, which somehow comes to (i,j -1), then by taking one, exactly one step, that path becomes one path to (i,j) right. So, every path from (0,0) to i minus, (i,j -1) can be extended in a unique way to (i,j). Likewise, any path, which comes from (0,0) to (i-1,j) can be extended in the unique way, right. So, if I count the task coming to the two neighbours, then each of those paths can be extended to reach the current node.

When navigating a grid, moving to a specific point (i, j) can only be accomplished from either the point directly to the left (i, j-1) or from the point directly below (i-1, j). This creates a unique path to (i, j) from both directions. For example, starting at the origin (0, 0), if you reach (i, j-1), you can simply step right to get to (i, j). Likewise, if you reach (i-1, j) from below, you can step up to reach (i, j). Thus, if you know the number of paths to the two neighboring points, you can add those together to find the number of paths to (i, j).

Imagine you're in a city represented by a grid where you can only move right or up. To get to a building located at (3, 2) from the starting point at (0, 0), you can arrive either from (3, 1) or (2, 2). Just like the paths in the grid, you can think of these streets connecting buildings—if you know how to reach the buildings directly next to yours, then you can easily figure out your own route.

So, if you look at our grid, in general, then if we look at the leftmost column, let us start the bottom row. Anything of the form (i,0) derives its value only from the left because there is no corresponding row from the left. Similarly, from the leftmost column, there is nothing from the left. So, I can only get it from j-1 from the row below.

When dealing with boundaries in a grid, the leftmost column (i,0) can only be reached from the row directly below it. This means that each point in the leftmost column must inherit its path count solely from the point below it. Similarly, any point in the top row (0,j) can only derive its path count from the point to its left, as there is no point to its left that it can inherit from.

Think of reaching a tall building (0, j) from the street (0, 0). In the first row directly above the street, you can only gather information and count paths from the previous building (0, j-1) to get to the next one. Meanwhile, the buildings down in the far left column (i, 0) can only get signals from the ones below them, like a chain reaction of unlocks leading up to the top!

So, if I am at (0,0) and I want to go to (0,0), how many ways are there? Well, this is a trivial path, there is only one way, by just staying there.

The initial condition in the grid is straightforward: there is exactly one way to stay in the starting position (0, 0)—by not moving at all. This ensures that any paths counting from (0, 0) always have a base value of 1, allowing subsequent calculations from this point to build on this fundamental path count.

Imagine you're starting a journey at your home (0, 0). The only way to remain in your home is by not leaving it. Think of this as your foundational starting point—every adventure or path you take builds off this initial position!

So, how do we deal with holes in this setup? That is easy, we just say, that whenever there is a hole at a given point we just declare parts of ((Refer Time: 11:52)) be 0.

Holes in the grid represent points where paths cannot pass through, effectively reducing the number of paths to 0 for those grid points. Whenever a hole appears, we simply ignore any potential paths leading to it from its neighbors. This ensures that the presence of a hole propagates a count of zero to its adjacent points, maintaining the integrity of the path count calculations.

Consider a sidewalk (grid) where some sections have construction barriers (holes). If you're counting how many ways you can walk through the area, those blocked sections mean you cannot pass through. Therefore, anyone trying to count their pathways would see a 0 for any paths leading to that construction zone, like a reminder that you cannot go that way!

So, how would we use dynamic programming on the grid? So, this is our grid with the two holes at the (2,4) and (4,4). The first thing is to identify DAG structure of the dependencies.

When leveraging dynamic programming for calculating paths on a grid with holes, we start by identifying the dependencies between cells, which can be visualized as a Directed Acyclic Graph (DAG). By understanding which cells depend on others (i.e., which path counts come from neighboring cells), we can determine an order of operations to calculate the number of paths efficiently, filling out the grid row by row or column by column.

Think about planning a delivery route (grid) while being aware of road closures (holes). You would first map out the streets, noting which intersections depend on others. This way, you can strategize the best route to deliver packages while avoiding blocked paths. It’s all about understanding the flow of dependencies to optimize the travel route.

So, this is the DAG structure, right. If you remember, if these depends on the two values, left and below, we draw an edge from the left to this node and from below to this node.

In the DAG notation, we represent each grid cell as a node, where edges lead from neighboring nodes (to the left or below) to signify the dependency of the path count. This structure helps in laying out a calculation that respects the dependencies, ensuring that each node's value is computed only when all prior dependencies are fully accounted for.

Imagine a network of influencers (nodes) who promote each other (dependencies). Each influencer relies on their connections to spread their message effectively. If an influencer in your network hasn't shared their content yet, those tied to them will have a delay in their reach—highlighting the importance of sequentially validating connections before moving on.

So, therefore, though this looks like a wasteful dynamic programming strategy in case the holes are distributed in a bad way. Actually, it does not matter. It usually turns out, that a dynamic programming implementation will be usually more efficient than a memoization implementation.

While dynamic programming might seem to be inefficient by computing values that appear useless (like points with holes), its structured, iterative method often leads to better overall efficiency compared to root memoization techniques. This is because dynamic programming systematically evaluates paths in a manner that considers all dependencies, reducing the risk of redundant calculations.

Think of a chef preparing a multi-course meal using batch cooking (dynamic programming). Instead of repeatedly calculating what ingredients are needed for each course (like memoization), they prepare all ingredients for multiple dishes at once. Even if some are leftover or seem unnecessary now, it allows for a smoother, faster cooking process as everything is prepped before service.

--