Calclulation of epoch length in UCB2 I am trying to understand the UCB2 algorithm presented in [1]. 
In step 2 of the algorithm, it says :

Play machine j exactly $\tau(r_j+1) - \tau(r_j)$ times,

where $\tau(r_j) = \lceil (1+\alpha)^{r_j}\rceil$ for $0<\alpha<1$
So, let’s say for example $\alpha = 0.001$ (which is the value used in their simulations). If $r_j=0$, meaning we played machine $j$ during $0$ epochs, then we have to play it exactly once. Then, if $r_j=3$ for example, i.e. machine $j$ has been played during 3 epochs in the past, according to the formula in step 2, we have to play it 0 times. 
As a result, I don't see how we can get an epoch length that grows as we play machine $j$ more.
I tried to look for more straightforward explanations of how UCB2 works in other papers, but they all use the same original explanation. 
So, any clarification of how the epoch length is determined would be much appreciated.
[1] Auer, Peter, Nicolo Cesa-Bianchi, and Paul Fischer. "Finite-time analysis of the multiarmed bandit problem." Machine learning 47.2-3 (2002): 235-256.
 A: Suppose that we have drawn $n$ values and that during the next step of the algorithm, we need to draw from the $j$-machine, because the quantity $\overline{x}_k+a_{n, r_k}$ is maximized for $k=j$. 
If $\tau(r_j+1)-\tau(r_j)=0$, then we do not draw a value and we proceed to Step 3. We set $r_j:=r_j+1$ and return to Step 1 for the next iteration.
Since no value was drawn, $n$ is the same as before. Also all the values of $\overline{x}_k+a_{n, r_k}$ remained unchanged for $k\neq j$. Additionally, for the $j$ machine, we   have that $r_j$ is equal to $r_j=r+1$ for some $r$ with the property that $\tau(r+1)=\tau(r)$. Plugging this into $a_{n,r_j}$, we obtain that
$$a_{n,r_j}=a_{n,r+1}=\sqrt{\frac{(1+a)\ln\frac{en}{\tau(r+1)}}{2\tau(r+1)}}=\sqrt{\frac{(1+a)\ln\frac{en}{\tau(r)}}{2\tau(r)}}=a_{n,r},$$
so the value of $a_{n,r_j}$ remained the same as well. 
This implies that when we repeat the Step 1 of the algorithm, the same machine $j$ will be picked again. But this time it will be played a total of $\tau(r+2)-\tau(r+1)$ times (instead of $\tau(r+1)-\tau(r)=0$ which occurred in the previous step). If this number also happens to be equal to zero, then after a finite number of iterations we will definitely end up with a non-zero quantity. This is obvious as $(1+a)^m\rightarrow \infty$, so for every $k\in \mathbb{N}$ there exists a minimum $n_k\in \mathbb{N}$ such that $(1+a)^{n_k}\geq k$. 
The algorithm contains some trivial iterations, in the sense that it doesn't draw any values from the proposed bandit during them, just to allow the value of $r_j$ to grow enough to catch up with the sequence $(n_k)_k$.
