**Amortized analysis** refers to determining the time-averaged running time for a sequence (not an individual) operation. It is different from average case analysis because here, we don’t assume that the data arranged in average (not very bad) fashion like we do for average case analysis for quick sort. That is, amortized analysis is worst case analysis but for a sequence of operation rather than an individual one. It applies to the method that consists of the sequence of operation, where a vast majority of operations are cheap but some of the operations are expensive. This can be visualized with the help of binary counter which is implemented below.

Let’s see this by implementing an increment counter in C. First, let’s see how counter increment works.

Let a variable **i** contains a value 0 and we performs i++ many time. Since on hardware, every operation is performed in binary form. Let binary number stored in 8 bit. So, value is 00000000. Let’s increment many time. So, the pattern we find are as :

00000000, 00000001, 00000010, 00000011, 00000100, 00000101, 00000110, 00000111, 00001000 and so on …..

**Steps :** **1.** Iterate from rightmost and make all one to zero until finds first zero. **2.** After iteration, if index is greater than or equal to zero, then make zero lie on that position to one.

## C++

`#include <bits / stdc++.h>` `using` `namespace` `std;` `int` `main()` `{` ` ` `char` `str[] = ` `"10010111"` `;` ` ` `int` `length = ` `strlen` `(str);` ` ` `int` `i = length - 1;` ` ` `while` `(str[i] == ` `'1'` `) {` ` ` `str[i] = ` `'0'` `;` ` ` `i--;` ` ` `}` ` ` `if` `(i >= 0)` ` ` `str[i] = ` `'1'` `;` ` ` `printf` `(` `"% s"` `, str);` `}` |

## Java

`import` `java.util.*;` `class` `GFG{` `public` `static` `void` `main(String args[])` `{` ` ` `String st = ` `"10010111"` `;` ` ` `char` `[] str = st.toCharArray();` ` ` `int` `lengthh = st.length();` ` ` `int` `i = lengthh - ` `1` `;` ` ` ` ` `while` `(str[i] == ` `'1'` `)` ` ` `{` ` ` `str[i] = ` `'0'` `;` ` ` `i--;` ` ` `}` ` ` ` ` `if` `(i >= ` `0` `)` ` ` `str[i] = ` `'1'` `;` ` ` ` ` `System.out.print( str);` `}` `}` `// This code is contributed by sanjoy_62` |

**Output: **

10011000

On a simple look on program or algorithm, its running cost looks proportional to the number of bits but in real, it is not proportional to a number of bits. Let’s see how!

Let’s assume that increment operation is performed k time. We see that in every increment, its rightmost bit is getting flipped. So, the number of flipping for LSB is k. For, second rightmost is flipped after a gap, i.e., 1 time in 2 increments. 3rd rightmost – 1 time in 4 increments. 4th rightmost – 1 time in 8 increments. So, the number of flipping is k/2 for 2nd rightmost bit, k/4 for 3rd rightmost bit, k/8 for 4th rightmost bit and so on …

Total cost will be the total number of flipping, that is,

C(k) = k + k/2 + k/4 + k/8 + k/16 + …… which is Geometric Progression series and also,

C(k) < k + k/2 + k/4 + k/8 + k/16 + k/32 + …… up to infinity

So, C(k) < k/(1-1/2)

and so, C(k) < 2k

So, C(k)/k < 2

Hence, we find that average cost for increment a counter for one time is constant and it does not depend on the number of bit. We conclude that increment of a counter is constant cost operation.

**References :**

- http://www.cs.cornell.edu/courses/cs3110/2013sp/supplemental/recitations/rec21.html
- http://faculty.cs.tamu.edu/klappi/csce411-s17/csce411-amortized3.pdf