# How does being on-policy prevent us from using the replay buffer with the policy gradients?

One of the approaches to improving the stability of the Policy Gradient family of methods is to use multiple environments in parallel. The reason behind this is the fundamental problem we discussed in Chapter 6, Deep Q-Network, when we talked about the correlation between samples, which breaks the independent and identically distributed (i.i.d) assumption, which is critical for Stochastic Gradient Descent (SDG) optimization. The negative consequence of such correlation is very high variance in gradients, which means that our training batch contains very similar examples, all of them pushing our network in the same direction. However, this may be totally the wrong direction in the global sense, as all those examples could be from one single lucky or unlucky episode. With our Deep Q-Network (DQN), we solved the issue by storing a large amount of previous states in the replay buffer and sampling our training batch from this buffer. If the buffer is large enough, the random sample from it is much better representation of the states distribution at large. Unfortunately, this solution won't work for PG methods, at most of them are on-policy, which means that we have to train on samples generated by our current policy, so, remembering old transitions is not possible anymore.

The above excerpt is from Maxim Lapan in the book Deep Reinforcement Learning Hands-on page 284.

How does being on-policy prevent us from using the replay buffer with the policy gradients? Can you explain to me mathematically why we can't use replay buffer with A3C for instance?

• I answered similar question here you can take a look – Brale May 15 '20 at 16:53

## 1 Answer

Let's say your old policy is $$\pi_b$$ and your current one is $$\pi_a$$. If you collected trajectory by using policy $$\pi_b$$ you would get return $$G$$ whose expected value is \begin{align} E_{\pi_b}[G_t|S_t = s] &= E_{\pi_b}[R_{t+1} + G_{t+1}]\\ &= \sum_a \pi_b(a|s) \sum_{s', r} p(s', r|s, a) [r + E_{\pi_b}[G_{t+1}|S_{t+1} = s']]\\ \end{align} You can see if you write out this recursively that this expectation depends on $$\pi_b(a|s), \pi_b(a'|s'), \ldots$$

If you collect trajectory with policy $$\pi_a$$ you would get expected return that depends on $$\pi_a(a|s), \pi_a(a'|s'), \ldots$$ Since these are two different policies then $$\pi_b(a|s) \neq \pi_a(a|s)$$ for some $$(s, a)$$. That would mean that returns have different expected values and are sampled through different distributions. You cannot then use some return $$G$$ sampled by following policy $$\pi_b$$ to update policy $$\pi_a$$ because it's not sampled according to the proper distribution, if we did, we would be updating policy $$\pi_a$$ with biased gradient update that does not reflect how policy $$\pi_a$$ performed.

• Or in more plain, non-mathematical terms; if you're traing on old examples stored in some replay buffer, which were created by another / an older policy, you're by definition doing off-policy learning! – Dennis Soemers May 15 '20 at 19:57
• Ok. I am working with the Max Lapan's book, i.e. Deep Reinforcement Learning Hands-on on the subject of A2C. I tried to build my own implementation of the Atari Pong game using that algorithm and based on Max code, but my code is not converging at all. I'm struggling on that converging issue for a week now. I think there's a very subtle error in the code, but I can't say what it is. Here is the question: ai.stackexchange.com/q/21187/2444. Can you help me with that? – jgauth May 15 '20 at 19:58
• Both code are running in a different Colab Env. You can probably see a very significant difference in the results ... right now. – jgauth May 15 '20 at 20:06
• I'm not sure if I will have time to look into code and I'm also not too familiar with Pytorch. If the other code is similar and it works try to change those lines that are different one portion at the time to try to spot the error. So my advice would be to try to isolate portions of the code and make sure they work and that they provide same behavior in both cases. To do that easier, you can also set the random seed so that you always initialize with the same parameters in both cases. – Brale May 15 '20 at 22:05
• for example in numpy you can call numpy.random.seed and your random numbers will always follow same pattern every time you run the program. – Brale May 15 '20 at 23:55