[PPT] - Amortized Analysis Chapter 17 1 CPTR 430 Algorithms Amortized PowerPoint Presentation

SLIDE 1

Amortized Analysis

Chapter 17

CPTR 430 Algorithms Amortized Analysis

1

SLIDE 2

Amortized Analysis

■ Amortized analysis averages the time required to perform a sequence

f operations on a data structure over all the operations performed

■ An individual operation may itself be relatively expensive, but its

average cost (amortized cost) may be small

■ Common types of amortized analysis: ❚ Aggregate analysis ❚ Accounting method ❚ Potential method

CPTR 430 Algorithms Amortized Analysis

2

SLIDE 3

Sample Applications

The sample applications are simple enough to see how the principles of amortized analysis apply

■ Augmented stack ■ Binary counter

CPTR 430 Algorithms Amortized Analysis

3

SLIDE 4

Augmented Stack

A normal stack with an additional operation: multiPop()

■ push(x)—pushes element x onto the stack, as usual ■ pop()—pops the top element off of the stack and returns the popped

element, as usual

■ multiPop(k) pops the top k elements off of the stack ❚ Returns true if k elements could be popped ❚ Returns false if fewer than k elements were popped because the

stack had fewer than k elements when the method was called

CPTR 430 Algorithms Amortized Analysis

4

SLIDE 5

The Implementation

public class Stack { private Object[] stack; // Array of elements private int top; // Next available position public Stack(int capacity) { stack = new Object[capacity]; top = 0; // Stack is initially empty } public boolean isEmpty() { return top == 0; } public int size() { return top; } public void push(Object newElement) { if ( top < stack.length ) { stack[top++] = newElement; } } public Object pop() { Object result = null; if ( top > 0 ) { result = stack[--top]; } return result; } public boolean multiPop(int k) { while ( !isEmpty() && k != 0 ) { pop(); k--; } return k == 0; // k elements successfully popped off? } } CPTR 430 Algorithms Amortized Analysis

5

SLIDE 6

Analysis of Stack Operations

■ push(x)—O

1

✁

■ pop()—O

1

✁

■ MultiPop(k)—min

✂

n

✄

k

☎

, where n is the size of the stack—worst case is O

n

✁

■ Consider a sequence of n stack operations on an initially empty stack ❚ The worst-case cost of a multiPop() is O

n

✁

, since the stack may contain n elements

❚ The worst-case time for any stack operation is thus O

n

✁

❚ A sequence on n stack operations, worst-case, would be O

n2

✁

(O

n

✁

multiPop() operations each costing O

n

✁

)

■ This bound is correct but not tight

(Why?)

CPTR 430 Algorithms Amortized Analysis

6

SLIDE 7

Binary Counter

■ Uses a fixed number of bits, k ■ The bits are stored in an array with length k ■ Lowest order bit is at index 0, so the counter’s value = k

1

∑

i

✁

A

✂

i

✄✆☎

2i

■ Counts upward from 0 to k

✝

1 (modulo 2k counter)

■ Flipping a bit counts as work ■ More work occurs when carries must be done ■ Incrementing the maximum representable value k bits

✞ ✟✠ ✡

1111

☛ ☛ ☛

1 (rolling it

ver to

k bits

✞ ✟ ✠ ✡

0000

☛ ☛ ☛

0) requires k bit flips

CPTR 430 Algorithms Amortized Analysis

7

SLIDE 8

The Implementation

public class BinaryCounter { private int[] bitString; public BinaryCounter(int bits) { // Java automatically initializes the contents to zero bitString = new int[bits]; } public String toString() { String result = ""; for ( int i = bitString.length - 1; i >= 0; i-- ) { result += bitString[i]; } return result; } public void increment() { int i = 0; while ( i < bitString.length && bitString[i] == 1 ) { bitString[i] = 0; i++; } if ( i < bitString.length ) { bitString[i] = 1; } } } CPTR 430 Algorithms Amortized Analysis

8

SLIDE 9

Analysis of the Binary Counter

■ A single execution of the increment() methods takes worst-case time

O

k

✁

(when the array contains all 1s)

■ Thus a sequence of n increments on a counter object that is initially

zero will take O

nk

✁

time, in the worst case

■ This bound is correct, but not tight

(Why?)

CPTR 430 Algorithms Amortized Analysis

9

SLIDE 10

Aggregate Analysis

■ In aggregate analysis, we show that for all n, a sequence of n operations

takes worst-case time T

n

✁

in total

■ The worst case amortized cost (or average cost) is thus T

n

✁

n

■ This amortized cost is then applied to each operation even though

different operations may have very different run times individually

CPTR 430 Algorithms Amortized Analysis

10

SLIDE 11

Aggregate Analysis of Stack Operations

■ Aggregate analysis can give a tighter upper bound for the sequence of

n stack operations

■ A single multiPop() operation can be expensive, but any sequence

f n push(), pop(), and multiPop() operations on an initially empty

stack can cost at most O

n

✁

(Why?)

■ Each item can be popped off at most once for each time it is pushed

the number of pop() calls, including the calls from

within multiPop() is at most the number of push() operations

■ The number of push() operations is at most n, so any sequence of n

push(), pop(), and multiPop() operations on an initially empty stack

takes at most O

n

✁

time

CPTR 430 Algorithms Amortized Analysis

11

SLIDE 12

Aggregate Analysis of Stack Operations (cont.)

■ The number of push() operations is at most n, so any sequence of n

push(), pop(), and multiPop() operations on an initially empty stack

takes at most O

n

✁

time

■ The average cost of an operation: O

n

✁

n

O
1

✁

■ Aggregate analysis assigns the amortized cost of each operation to be

the average cost

■ The amortized cost of all three stack operations (even multiPop()) is

O

1

✁

CPTR 430 Algorithms Amortized Analysis

12

SLIDE 13

Aggregate Analysis of the Binary Counter

■ Notice that not all bits flip every time increment() is called ❚ bitString[0] flips every time

A sequence of n increments causes it to flip n times

❚ bitString[1] flips every other time

A sequence of n increments causes it to flip

n
2

✁

times

❚ bitString[2] flips every fourth time

A sequence of n increments causes it to flip

n
4

✁

times

■ For i

✄

1

✄ ☛ ☛ ☛ ✄

lgn

✁

, bit bitString[i] flips

n
2i

✁

times in a sequence of n increments starting with a zero counter

■ For i

✂

lgn

✁

, bit bitString[i] does not flip at all

CPTR 430 Algorithms Amortized Analysis

13

SLIDE 14

Aggregate Analysis of the Binary Counter (cont.)

The total number of flips in the sequence is

lgn

✁

∑

i

✁

n 2i

✂

n

∞

∑

i

✁

1 2i

2n

✠ ✡ ✞ ✟

(See Page 1060) The worst-case time for a sequence of n increment() operations on an initially zero counter is thus

O

n

✁

The average cost per operation (amortized cost) is therefore

O

n

✁

n

O
1

✁

CPTR 430 Algorithms Amortized Analysis

14

SLIDE 15

Aggregate Analysis of the Binary Counter (cont.)

Counter Bit Current Total Value 7 6 5 4 3 2 1 Cost Cost 1 1 1 2 1 2 1 1 3 3 1 1 3 4 4 1 1 7 5 1 1 2 8 6 1 1 1 10 7 1 1 1 4 11 8 1 1 15 9 1 1 2 16 10 1 1 1 18 11 1 1 1 3 19 12 1 1 1 22 13 1 1 1 2 23 14 1 1 1 1 25 15 1 1 1 1 5 26 16 1 1 31

CPTR 430 Algorithms Amortized Analysis

15

SLIDE 16

The Accounting Method

■ The

accounting method charges differing amounts to different

perations

■ Some operations may be charged more or less than they actually cost ■ The amount charged to an operation is its amortized cost ■ Operations charged more than their actual cost build credit stored

within a specific object

■ This credit can be used to help pay for operations that are charged less

than their actual cost

■ Note that this approach is different from aggregate analysis in which all

perations are charged the same amortized cost

CPTR 430 Algorithms Amortized Analysis

16

SLIDE 17

The Accounting Method (cont.)

■ We want the worst case analysis to show that the amortized (average)

cost per operation is small, even though a given operation may in and

f itself be expensive

(This is exactly the point of aggregate analysis, also)

■ We must show that the total amortized cost of a sequence of operations

is an upper bound on the total actual cost of the sequence of operations

❚ This relationship must hold for all sequences ❚ Therefore, the applied credit can never be negative ❚ Should the credit be allowed to become negative, then the cost of the

amortized sequence to that point would be less than the actual cost to that point, and so the amortized cost would violate the upper-bound relationship

CPTR 430 Algorithms Amortized Analysis

17

SLIDE 18

The Accounting Method (cont.)

■ Let ci be the actual cost of operation i ■ Let

ci be the amortized cost of operation i

■ The constraint that the amortized cost be an upper bound on the actual

cost can be expressed as

n

∑

i

✁

1

ci

✁

n

∑

i

✁

1

ci

for all sequences of n operations

■ The total credit is the difference between the amortized cost and the

actual cost

n

∑

i

✁

1

ci

✝

n

∑

i

✁

1

ci

(Do you see why this must be non-negative?)

CPTR 430 Algorithms Amortized Analysis

18

SLIDE 19

The Stack Example

Operation Actual Cost Amortized Cost

push()

1 2

pop()

1 multiPop()

min

✂

n

✄

k

☎

As with the aggregate analysis, all three operations have amortized costs

f O
1

✁

Can we pay any sequence of stack operations by charging simply the amortized costs?

CPTR 430 Algorithms Amortized Analysis

19

SLIDE 20

The Stack Example (cont)

Operation Actual Cost Amortized Cost push()

1 2

pop()

1 multiPop()

min

n

✁

k

✂

■ Every push() operation is not only charged its actual cost (1), but an additional cost

f 1 for prepayment for any future pop() operation, whether it be from a single pop,
r multiple pops from within multiPop()

■ This credit is associated with the object pushed onto the stack ■ The operations pop() and multiPop() need be charged nothing, as their cost has

already been paid

■ When an object is popped off, the credit associated with that object pays for the pop

peration

■ Thus for any sequence of n push(), pop(), and multiPop() operations, the total

amortized cost is an upper bound on the total actual cost

■ The total amortized cost is O

✄

n

☎

, and so is the total actual cost

CPTR 430 Algorithms Amortized Analysis

20

SLIDE 21

The Binary Counter Example

■ The running time of increment() is proportional to the number of bits

flipped

■ Thus, the cost to flip a bit is 1 ■ Let the amortized cost to flip a bit from 0 to 1 be 2: ❚ 1 to flip the bit to 1, plus ❚ 1 credit, stored with that bit, to flip the bit back to 0 ■ Let the amortized cost to flip a bit from 1 to 0 be 0: ❚ Cash in on the stored credit of 1 when it was previously made a 1

CPTR 430 Algorithms Amortized Analysis

21

SLIDE 22

Amortized Analysis of Binary Counter

Bit Current Total

Cur. Am.

Current

Tot. Am.

7 6 5 4 3 2 1 Cost Cost Cost Credit Cost 1 2 1 2 1 2 1 2 1 1 3 2 1 4 1 1 3 4 2 2 6 1 1 7 2 1 8 1 1 2 8 2 2 10 1 1 1 10 2 2 12 1 1 1 4 11 2 3 14 1 1 15 2 1 16 1 1 2 16 2 2 18 1 1 1 18 2 2 20 1 1 1 3 19 2 3 22 1 1 1 22 2 2 24 1 1 1 2 23 2 3 26 1 1 1 1 25 2 3 28 1 1 1 1 5 26 2 4 30 1 1 31 2 1 32

CPTR 430 Algorithms Amortized Analysis

22

SLIDE 23

The Potential Method

■ The accounting method represents prepaid work as credit associated

with specific objects within a data structure E.g., a object pushed onto a stack or a bit set to 1

■ The potential method represents the prepaid work as “potential energy”

within the system

■ This potential energy (or just potential) is not associated with any

particular object

■ This potential can be used to pay for future operations

CPTR 430 Algorithms Amortized Analysis

23

SLIDE 24

Amortization in the Potential Method

■ D0—the intial data structure upon which n operations are to be

performed (e.g., empty stack or zero counter)

■ ci—the actual cost of the ith operation, 1

i
n

■ Di—the data structure that results after applying the ith operation to

data structure Di

1

■ Φ—the potential function that maps each data structure Di to a real

number Φ

Di

✁

This is the potential associated with data structure Di

■

ci—the amortized cost of the ith operation with respect to potential

function Φ

CPTR 430 Algorithms Amortized Analysis

24

SLIDE 25

Amortized Cost

ci, the amortized cost, is the actual cost plus the increase in potential due

to the operation:

ci
ci
Φ
Di

✁ ✝

Φ

Di
1

✁

The amortized cost of n operations is:

n

∑

i

✁

1

ci
n

∑

i

✁

1

ci
Φ
Di

✁ ✝

Φ

Di
1

✁ ✁

n

∑

i

✁

1

ci

n

∑

i

✁

1

Φ
Di

✁ ✝

Φ

Di
1

✁ ✁

n

∑

i

✁

1

ci

Φ
Dn

✁ ✝

Φ

D0

✁

(See Page 1061)

CPTR 430 Algorithms Amortized Analysis

25

SLIDE 26

Upper Bound

n

∑

i

✁

1

ci
n

∑

i

✁

1

ci

Φ
Dn

✁ ✝

Φ

D0

✁

■ Φ

Dn

✁ ✁

Φ

D0

✁

n

∑

i

✁

1

ci is an upper bound on

n

∑

i

✁

1

ci

■ Since we may not know in advance exactly how many operations will

be performed, we require

Φ

Di

✁ ✁

Φ

D0

✁ ✄

i

❚ This says we “pay in advance” ❚ This ensures that the amortized cost is always an upper bound ■ Usually, Φ

D0

✁

is defined to be 0

■ Our task is then to show that

i

✄

Φ

Di

✁ ✁

Φ

D0

✁

CPTR 430 Algorithms Amortized Analysis

26

SLIDE 27

Effect of an Individual Operations

■ Φ

Di

✁ ✝

Φ

Di
1

✁ ✂

❚ the potential of the data structure increases

❚ the amortized cost

ci is an overcharge to the ith operation

■ Φ

Di

✁ ✝

Φ

Di
1

✁ ✂

❚ the potential of the data structure decreases

❚ the amortized cost

ci is an undercharge to the ith operation

CPTR 430 Algorithms Amortized Analysis

27

SLIDE 28

Stack Example

■ Let Φ be the number of objects on the stack ■ For an empty stack, Φ

D0

✁

■ The stack can never contain a negative number of objects, so Di

✁

0,

far all i:

Φ

Di

✁ ✁

Φ
D0

✁

Again, this guarantees we pay in advance (always maintain an upper bound)

CPTR 430 Algorithms Amortized Analysis

28

SLIDE 29

Amortized Cost of push()

■ Let the ith operation on a stack containing s objects be a push() ■ The potential difference is

Φ

Di

✁ ✝

Φ

Di
1

✁

s
1

✁ ✝

s

1

■ Given our formula for amortized cost, we get

ci
ci
Φ
Di

✁ ✝

Φ

Di
1

✁

1
1
2

CPTR 430 Algorithms Amortized Analysis

29

SLIDE 30

Amortized Cost of pop()

■ Let the ith operation on a stack containing s objects be a pop() ■ ci, the actual cost of the operation, is 1 ■ The potential difference is

Φ

Di

✁ ✝

Φ

Di
1

✁

s

✝

1

✁ ✝

s

✝

1

■ Given our formula for amortized cost, we get

ci
ci
Φ
Di

✁ ✝

Φ

Di
1

✁

1
✝

1

✁

CPTR 430 Algorithms

Amortized Analysis

30

SLIDE 31

Amortized Cost of multiPop()

■ Let the ith operation on a stack containing s objects be a multiPop(k) ■ k

min

✂

k

✄

s

☎

bjects are popped off the stack

■ ci, the actual cost of the operation, is k

■ The potential difference is

Φ

Di

✁ ✝

Φ

Di
1

✁

s

✝

k

✁

✝

s

✝

k

■ Given our formula for amortized cost, we get
ci
ci
Φ
Di

✁ ✝

Φ

Di
1

✁

k
✝

k

✁
CPTR 430 Algorithms

Amortized Analysis

31

SLIDE 32

Amortized Analysis of Stack Operations

Using the potential method:

■ The amortized cost of each of the operations is O

1

✁

■ The total amortized cost for a sequence of n operations is thus O

n

✁

■ We showed that the amortized cost of n operations is an upper bound

n the actual cost

■ Therefore, the worst-case cost of n operations is O

n

✁

CPTR 430 Algorithms Amortized Analysis

32

SLIDE 33

Binary Counter Example

■ Define the potential of the counter after the ith increment to be bi, the

number of 1s in the counter after the ith operation

❚ Φ

D1

✁

b1
1 (0. . . 000
0. . . 001)

❚ Φ

D2

✁

b2
1 (0. . . 001
0. . . 010)

❚ Φ

D3

✁

b3
2 (0. . . 010
0. . . 011)

■ Suppose the ith increment resets ti bits ■ ci, the actual cost, is at most ti

1 (when the counter wraps to zero the

cost is just ti, since no bit is set to 1 is this case)

■ bi

the ith operation resets all k bits, so bi
1
ti
k

■ bi

✂

bi
bi
1

✝

ti

1

CPTR 430 Algorithms Amortized Analysis

33

SLIDE 34

Amortized Cost

bi

bi
1
ti
k

bi

✂

bi
bi
1

✝

ti

1
bi
bi
1

✝

ti

1

The potential difference is

Φ

Di

✁ ✝

Φ

Di
1

✁

bi
1

✝

ti

1

✁ ✝

bi

1
1

✝

ti

The amortized cost is

ci
ci
Φ
Di

✁ ✝

Φ

Di
1

✁

t1
1

✁

1

✝

ti

✁

2

CPTR 430 Algorithms Amortized Analysis

34

SLIDE 35

The Final Analysis

■ For a counter starting at 0, Φ

D0

✁

■
i Φ
Di

✁ ✁

the total amortized cost is an upper bound on the total

actual cost

■ The worst case cost of n increment() operations is thus O

n

✁

CPTR 430 Algorithms Amortized Analysis

35

SLIDE 36

Amortized Analysis of Binary Counter

Bit Current Total

Cur. Am.

Current

Tot. Am.

7 6 5 4 3 2 1 Cost Cost Cost Potential Cost 1 2 1 2 1 2 1 2 1 1 3 2 1 4 1 1 3 4 2 2 6 1 1 7 2 1 8 1 1 2 8 2 2 10 1 1 1 10 2 2 12 1 1 1 4 11 2 3 14 1 1 15 2 1 16 1 1 2 16 2 2 18 1 1 1 18 2 2 20 1 1 1 3 19 2 3 22 1 1 1 22 2 2 24 1 1 1 2 23 2 3 26 1 1 1 1 25 2 3 28 1 1 1 1 5 26 2 4 30 1 1 31 2 1 32

CPTR 430 Algorithms Amortized Analysis

36

SLIDE 37

Dynamic Arrays

■ In programming

languages like C, C++, C#, and Java, the size of an array must be supplied at the time of its creation E.g., a composite

bject that allows the

dynamic addition of parts (like a Java

JPanel with child JComponent parts)

CPTR 430 Algorithms Amortized Analysis

37

SLIDE 38

Dynamic Arrays

■ In many applications the maximum needed size may not be known

when the array is created

■ Erring on the side of safety (allocating an incredibly large array, just in

case) means wasted storage

■ The conservative approach (allocating the minimum required for the

moment and enlarging the array when necessary) has the potential for a lot work

❚ A new array must be created of the needed size ❚ All the elements in the existing array must be copied over into the

new array

❚ This activity is necessary since array elements must occupy

contiguous memory locations

CPTR 430 Algorithms Amortized Analysis

38

SLIDE 39

Amortized Analysis of Dynamic Arrays

■ Amortized analysis can be used to show that the cost of insertion into a

dynamic array is O

1

✁

, even though the actual cost of an insertion can be quite high if the insertion requires the array’s size to be expanded

■ Amortized analysis can also be used to show that the unused space in

a dynamic array never exceeds a constant fraction of its total space

CPTR 430 Algorithms Amortized Analysis

39

SLIDE 40

Load Factor

■ For a non-empty array T, the load factor, α

T

✁

, is the number of elements in the array divided by the allocated size of the array

■ A full array has a load factor of 1 ■ An empty array (allocated size

0) is defined to have a load factor of

1 (it is holding all it can)

■ If the load factor of a dynamic array is bounded below by a constant,

then the unused space in the table is never more than a constant fraction of the total amount of space

CPTR 430 Algorithms Amortized Analysis

40

SLIDE 41

Array Expansion

■ To insert an item into a full array, the array must be expanded ■ A common strategy: make the new array twice as big as the filled array ❚ This ensures the load factor will always be at least 1

2

❚ The amount of unused space never exceeds 1

2 the total allocated

space for the array

CPTR 430 Algorithms Amortized Analysis

41

SLIDE 42

The Implementation

public class DynamicArray { private Object[] array; private int numberOfElements; // Number of elements public DynamicArray() { this(0); // Zero-size array } public DynamicArray(int initialCapacity) { array = new Object[initialCapacity]; numberOfElements = 0; } public Object get(int pos) { if ( pos < numberOfElements && pos >= 0 ) { return array[pos]; } return null; } public void insert(Object newElement) { // Details on next slide . . . } }

CPTR 430 Algorithms Amortized Analysis

42

SLIDE 43

The insert() Method

public class DynamicArray { // See previous slide for other details . . . public void insert(Object newElement) { if ( array.length == 0 ) { array = new Object[1]; numberOfElements = 0; } if ( array.length == numberOfElements ) { Object[] newArray = new Object[2*array.length]; // forall i, newArray[i] <-- array[i] System.arraycopy(array, 0, newArray, 0, numberOfElements); array = newArray; } array[numberOfElements++] = newElement; } }

CPTR 430 Algorithms Amortized Analysis

43

SLIDE 44

Our Optimization

■ The code within insert():

System.arraycopy(array, 0, newArray, 0, numberOfElements);

is an optimization of

for ( int i = 0; i < numberOfElements; i++ ) { newArray.insert(array[i]); }

■ Notice that this simply a number of elementary insertions ■ If an insertion causes an array expansion, then the cost of the insertion

incurs the cost of re-inserting all the elements that were already there

CPTR 430 Algorithms Amortized Analysis

44

SLIDE 45

(Non-amortized) Analysis of Insert

Consider a sequence of n insertions on an initially empty dynamic array:

■ Assumption: The time to allocate a new array is dominated by the cost

to transfer the items from the old array Thus we can concentrate our attention on the number of elementary insertions

■ ci is the cost of the ith insertion ■ If there is room in the current array, ci

1

■ If the array is full, then ci

i:

❚ 1, for the elementary insertion of the new element, plus ❚ i

✝

1, to insert the existing elements into the newly created array

CPTR 430 Algorithms Amortized Analysis

45

SLIDE 46

The Bottom Line

■ If n insertions are performed, the worst case cost of a single insertion

peration is O
n

✁

■ For n insertions then, the total running time is bounded by O

n2

✁

■ As in our earlier analyses, this bound is correct but not tight ❚ The cost of expanding the array is not incurred often ❚ The ith insertion causes an expansion only when i

✝

1 is a power of 2

■ What, then, is the amortized cost for insert()?

CPTR 430 Algorithms Amortized Analysis

46

SLIDE 47

The Amortized Cost ´ a l` a Aggregate Analysis

ci

i

if i

✝

1 is an exact power of 3 1

therwise

The total cost for n insertions is

n

∑

i

✁

1

ci

n
lgn

✁

∑

j

✁

2 j

✂

n

2n
3n

since there are at most n operations that cost 1 and the costs of the remaining operations form a geometric series

n insertions cost 3n

each insertion operation has an amortized cost of 3

CPTR 430 Algorithms Amortized Analysis

47

SLIDE 48

The Amortized Cost ´ a l` a the Accounting Method

■ Aggregate analysis showed each operation had a cost of 3 ■ In the accounting method we will charge 3 for each insertion: ❚ The insertion of the element itself costs 1 ❚ A credit of 1 is associated with this element to cover its own move

when the array eventually needs to be expanded

❚ Another credit of 1 is associated with this element to cover the move

f another element when the array eventually needs to be expanded;

this other element was inserted before the previous expansion

CPTR 430 Algorithms Amortized Analysis

48

SLIDE 49

Accounting Specifics

For example, let the array’s size be m immediately after an expansion

■ The number of elements in the array is thus m

2

■ The array contains no credit ■ Charge a cost of 3 for each insertion: ❚ 1 for inserting the new element ❚ 1 as credit to move this element in the future ❚ 1 as credit to move one of the m

2 elements already in the array

■ The array will become full with m elements after m

2 insertions

■ When full, the total credit is 2

✄

m

2

☎ ✁

m, the exact amount needed to re-insert all m

existing elements when the array must be expanded

■ The expansion will consume all the credit, again leaving a new array twice as large

as the previous with no accumulated credit

CPTR 430 Algorithms Amortized Analysis

49

SLIDE 50

The Amortized Cost ´ a l` a the Potential Method

■ Keying on our accounting method analysis, define a potential function

Φ such that:

❚ Φ is 0 immediately after an expansion ❚ Φ increases as elements are inserted ❚ Φ is equal to the array size by the time the array is full ■ For dynamic array A, let ❚ num

A

✁

be the number of elements in A (logical size)

❚ size

A

✁

be the allocated size of the array (physical size)

Φ

A

✁

2

☎

num

A

✁ ✝

size

A

✁

CPTR 430 Algorithms Amortized Analysis

50

SLIDE 51

The Potential Function

■ From the previous slide

Φ

A

✁

2

☎

num

A

✁ ✝

size

A

✁

■ Immediately after an expansion

num

A

✁

size
A

✁

2

Φ
A

✁

■ Immediately before an expansion

num

A

✁

size
A

✁

Φ
A

✁

num
A

✁

■ The table is always at least half full, so

num

A

✁ ✁

size

A

✁

2

Φ
A

✁ ✁

CPTR 430 Algorithms Amortized Analysis

51

SLIDE 52

Amortized Cost is an Upper Bound on the Actual Cost

Φ

A

✁ ✁

The sum of the amortized costs of n

insertion operations is an upper bound of the sum of the actual costs So what is the amortized cost of an insertion based on the potential method?

CPTR 430 Algorithms Amortized Analysis

52

SLIDE 53

The Amortized Cost

■ Let ❚ numi be the number of elements in the array after the ith insertion ❚ sizei be the size of the array after the ith insertion ❚ Φi be the potential after the ith insertion ■ Initially ❚ num0

❚ size0
❚ Φ0
■ There are two cases:

❚ The ith insertion does not trigger an expansion ❚ The ith insertion does trigger an expansion

CPTR 430 Algorithms Amortized Analysis

53

SLIDE 54

The Amortized Cost–Case 1

The ith insertion does not trigger an expansion

■ sizei

sizei
1

■ Amortized cost

ci
ci
Φi

✝

Φi

1
1
2

☎

numi

✝

sizei

✁ ✝

2

☎

numi

1

✝

sizei

1

✁

1
2

☎

numi

✝

sizei

✁ ✝

2
numi

✝

1

✁ ✝

sizei

✁

1
2

☎

numi

✝

sizei

✝

2

☎

numi

✝

2

✝

sizei

✁

1
2

☎

numi

✝

sizei

✝

2

☎

numi

2
sizei
1
2
2

☎

numi

✝

2

☎

numi

✝

sizei

sizei
3

CPTR 430 Algorithms Amortized Analysis

54

SLIDE 55

The Amortized Cost–Case 2

The ith insertion does trigger an expansion

■ sizei

2

☎

sizei

1

■ sizei

1
numi
1
numi

✝

1

sizei
2

☎

numi

✝

1

✁

■ Amortized cost

ci
ci
Φi

✝

Φi

1
numi
2

☎

numi

✝

sizei

✁ ✝

2

☎

numi

1

✝

sizei

1

✁

numi
2

☎

numi

✝

2

☎

numi

✝

1

✁ ✁ ✝

2
numi

✝

1

✁ ✝

numi

✝

1

✁ ✁

numi
2

☎

numi

✝

2

☎

numi

2

✁ ✝

2

☎

numi

✝

2

✝

numi

1

✁

numi
2

☎

numi

✝

2

☎

numi

2

✝

2

☎

numi

2
numi

✝

1

numi
numi
2

☎

numi

✝

2

☎

numi

✝

2

☎

numi

2
2

✝

1

3

CPTR 430 Algorithms Amortized Analysis

55