Bootstrapping means updating a guess from another guess. Imagine you walk down a corridor of eight rooms. Every step pays 0, and only leaving the last room pays 1. So how does the first room learn that it's on a good path, when the only reward shows up seven steps later?
Part 2. Previously: the Q table.
The reward comes at the end
The simplest answer is to wait. You finish the walk, add up the rewards that came after each room, and move each room's estimate toward that total. That's Monte Carlo prediction. With no discount, every room's total is 1, so with a step size of 1 a single walk sets all eight rooms to 1 (the top row of the drawing).
The catch is the waiting. If an episode lasts a million steps, nothing gets updated for a million steps, and a task that never ends never hands you a total at all. Some policies never finish at all, as in the windy gridworld of Sutton and Barto, Example 6.5.
So let's learn during the walk instead. When you leave a room you don't know the final total yet, but you do have a current estimate for the next room. Take the reward you just got, add that estimate, and use the sum as your target. That borrowing is bootstrapping, and its one-step version is called TD(0), for temporal difference.
Credit moves back one room per walk
In the corridor, start every estimate at 0 and update each room right after you leave it, walking forward, with step size and discount both 1. On walk 1 only room 8 sees the reward. On walk 2, room 7 reads the now-correct value of room 8, and so on, so room 1 has to wait for walk 8 (the lower rows). Every update happens immediately, but credit still travels slowly. That slowness comes from the forward order, and replaying the walk backward would carry the reward across in one pass.
One borrowed update
Here's one update with real numbers. You're in a room whose estimate is 0.2. You move on, the reward is 0, and the next room's estimate is 0.8. With a discount of 0.9, the target is . With a step size of 0.5 you move halfway from 0.2 toward 0.72, which gives 0.46.
The reward was zero. All of the new information came from the next room's estimate.
What borrowing costs
Borrowing is only as good as the estimate you borrow. Say the next room's 0.8 is really 0.2 too high. Then this room comes out 0.09 too high after its update, and the room before it picks up about 0.04 the next time it borrows. The error travels back along the same path as the credit. You stop waiting, and in exchange you trust a guess.
There's a middle ground. An n-step target adds up n real rewards and only then borrows an estimate. In the same corridor, a three-step target credits all eight rooms in three walks instead of eight, and once n reaches the end of the episode it's just the Monte Carlo total again. Longer targets lean more on real rewards, which can be noisy, and less on the guess, which can be wrong.
When many states share one set of estimates, a wrong borrowed value can spread even further. Part 3: function approximation picks up there.
The exact targets, their conditions and sources
Let be the current step, its state and the reward after the action taken there. The episode ends at step , is the discount between 0 and 1, and counts steps ahead. The return adds the discounted rewards, and a fixed policy's value is the expected return (Sutton and Barto, Chapter 3):
With no discount, every nonterminal room in the deterministic corridor is worth 1.
Monte Carlo. Move each visited state toward its completed return, with step size . With a fixed policy, finite-variance returns, enough visits and suitably shrinking step sizes, the estimate settles toward the expected return (Section 5.1).
TD(0). Split the return as and replace by the current estimate of the next state. The terminal state's value is 0. For a finite discounted task, or an episodic task with bounded expected episode length, suitable on-policy visits and step sizes give convergence in the tabular case (Sections 6.1 and 6.2).
n-step TD. Let be the number of real rewards available before the episode ends. The target uses those rewards and borrows only at the endpoint, unless the endpoint is terminal (Section 7.1):
Corridor counts. Zero initial values, , online updates in forward order. Monte Carlo credits all eight rooms after walk 1. Forward TD(0) credits the last rooms after walk , so room 1 needs 8 walks. Three-step TD with the usual delayed updates and a terminal flush credits rooms 6 to 8 on walk 1, rooms 3 to 5 on walk 2 and rooms 1 and 2 on walk 3. These counts come from the update order and settings. They don't rank the methods in general, and backward replay would credit the whole corridor in one pass.
Choosing the horizon. Let be the estimation error. Before termination, the borrowed tail adds to the target's error. The discount shrinks a given endpoint error as grows, but the endpoint itself changes with , so this doesn't guarantee that bias or variance always rises or falls with the horizon. Noisy rewards, correlated transitions and the accuracy of different endpoint estimates all matter (Chapters 6 and 7).
Give actions credit: Generalized Advantage Estimation (GAE)
So far we estimated values under a fixed policy. To improve the policy, a good outcome alone doesn't tell you whether an action helped, because the starting state may already have been promising. The advantage compares an action's expected return with the policy's usual return from that state:
Here means taking first and then following , and also averages over the first action. Generalized Advantage Estimation (GAE) estimates this credit from experience and an approximate state value . Collect a rollout with a fixed policy, keep the data and fixed, and take one segment ending at , with counting steps ahead:
The parameter , between 0 and 1, sets how much later errors count. Adding the TD errors of one return length makes the intermediate values cancel, leaving that return minus the starting value, and GAE is a geometrically weighted mix of those return lengths (Schulman et al., Section 3, equations 14 to 16). It brings the same horizon tradeoff to action credit, and changing doesn't guarantee a particular change in variance.
A small example: three transitions ending at a terminal state, , rewards and frozen values . The errors are . With , the credit for is
| TD error | Weight | Credit |
|---|---|---|
| 1 | 0 | |
| 0.5 | −0.5 | |
| 0.25 | 0.75 | |
| Total | 0.25 |
At only remains, so the credit is 0. At the sum is , the completed return minus the starting value. A value like is a decay factor, not a 95% and 5% mixture.
The same sum has a backward recurrence, and . To apply it to a batch, split at every episode reset and use the last actual observation as . Set only at a true terminal state. A time limit that cuts an ongoing task, or a rollout cutoff, keeps its bootstrap value, and the trace still stops at the boundary, as in Spinning Up's finish_path.
# One segment, with frozen values and no episode reset inside it.
endpoint = 0 if true_terminal else V(last_actual_observation)
v[H] = endpoint
advantage[H] = 0
for t = H-1 down to 0:
delta = R_(t+1) + gamma * v[t+1] - v[t]
advantage[t] = delta + gamma * lambda * advantage[t+1]
When the clock ends the episode
That rule assumes you know whether an ending is real. Training runs usually stop every episode after a fixed number of steps, and that cutoff can mean two different things. Pardo et al. (2018) separate them.
The time limit is part of the task. Say the robot really has 14 moves to reach a goal. Then a state's value depends on how many moves are left, and if the state doesn't include the remaining time, two different situations look identical and the learner averages targets that disagree. Their fix is to put the remaining time in the input. In their Last Moment example, the agent can stay for reward 0 or jump into a trap that pays +1 once and then −1 on every step until the end. The best plan is to stay and jump on the very last step. An agent that can't see the clock can't tell when the last step is, and the paper notes that even Monte Carlo methods, which don't bootstrap, can't learn the right plan without the time input.
The time limit is only for training. If the task would really go on, the cutoff isn't an end. Treating it as terminal teaches the learner that states near the cutoff have less future ahead, so their values come out wrong even though nothing about them changed. Their fix is partial-episode bootstrapping: at the cutoff, use instead of .
| How the limit is meant | Value depends on | Target at the limit | Fix from Pardo et al. |
|---|---|---|---|
| Part of the task | State and time left | Real end: last reward only | Add the remaining time to the input |
| Only for training | State only | Not an end: bootstrap from | Partial-episode bootstrapping |
My game Breaking Bellman has a pass-or-fail goal grid where this seems to happen: 14 moves, reward 1 at the goal and 0 otherwise, no discount. PPO with a learned value and GAE solved 13.3% of the tasks, and its value estimate at the start was about 1.44, above the largest possible return of 1. Scoring actions with real completed returns instead solved 95%, and with no baseline at all, 100% (3 seeds, simulation). The game's own reading is that the value bootstraps through the time limit and can't see the clock. Those are two different problems. The start value above 1 fits bootstrapping past a real ending, since no return in this task can exceed 1. Failing on the timed task also fits a missing clock, as in the Last Moment example, but the log has no run with the remaining time in the input, so that part is unconfirmed.