[PDF] - 394 Chapter 15 Priorit y Queues Chapter Ov erview A PDF Document

SLIDE 1 394

SLIDE 2 Chapter 15 Priorit y Queues Chapter Ov erview A priority queue is a data structure useful in problems where it is imp

rtan

t to b e able to rapidly and rep eatedly nd and remo v e the largest elemen t from a collection

f

v alues. In this c hapter w e will presen t t w

dieren

t implemen tations

f

priorit y queues. The rst tec hnique uses an abstraction called a he ap, and is constructed as an adaptor built

n

top another form

f

con tainer, t ypically a v ector

r

deque. The heap data structure is then used to demonstrate y et another approac h to sorting a collection

f

v alues. The second implemen tation strategy is the skew he ap. The sk ew heap is notable in that it do es not pro vide guaran teed p erformance b

unds

for an y single

p

eration, but it can b e sho wn that if a n um b er

f
p

erations are p erformed

v

er time the a v erage execution time

f
p

erations will b e small. As a demonstration

ne
f

the more common uses

f

heap, the c hapter concludes with a discussion

f

discrete ev en t driv en sim ulation. This topic is approac hed b y rst dev eloping a general fr amework for sim ulations, then sp ecializing the framew

rk

using inheritanc e.

The

priorit y queue data abstraction

Heaps

and heap sort

Sk

ew heaps

A

framew

rk

for sim ulation

Discrete

Ev en t-driv en sim ulation 395

SLIDE 3 396 CHAPTER 15. PRIORITY QUEUES 15.1 The Priorit y Queue Data Abstraction An ev eryda y example

f

a priorit y queue is the \to do" list

f

tasks w aiting to b e p erformed that most

f

us main tain to k eep

urselv

es

rganized.

Some jobs, suc h as \clean desktop", are not imp erativ e and can b e p

stp
ned

arbitrarily . Other tasks, suc h as \nish rep

rt

b y Monda y"

r

\buy

w

ers for anniv ersary", are time crucial and m ust b e addressed more rapidly . Therefore, w e sort the tasks w aiting to b e accomplished in

rder
f

their imp

rtance

(or p erhaps based

n

a com bination

f

their critical imp

rtance,

their long term b enet, and ho w m uc h fun they are to do) and c ho

se

the most pressing. F

r

a more computer-related example, an

p

erating system migh t use a priorit y queue to main tain a collection

f

curren tly activ e pro cesses, where the v alue asso ciated with eac h elemen t in the queue represen ts the urgency

f

the task. It ma y b e necessary to resp

nd

rapidly to a k ey pressed at a w

rkstation,

for example, b efore the data is lost when the next k ey is pressed. Other tasks can b e temp

rarily

p

stp
ned

in

rder

to handle those that are time critical. F

r

this reason a priorit y queue is used so that the most urgen t task can b e quic kly determined and pro cessed. Another example migh t b e les w aiting to b e

utput
n

a computer prin ter. It w

uld

b e a reasonable p

licy

to prin t sev eral

ne

page listings b efore a

ne

h undred-page job, ev en if the larger task w as submitted earlier than the smaller

nes.

F

r

this reason a queue w

uld

main tain les to b e prin ted in

rder
f

size,

r

a com bination

f

size and

ther

factors, and not simply

n

time

f

submission. A sim ulation, suc h as the

ne

w e will describ e in Section 15.4, can use a priorit y queue

f

\future ev en ts", where eac h ev en t is mark ed with a time at whic h the ev en t is to tak e place. The elemen t in this collection with the closest follo wing time is the next ev en t that will b e sim ulated. As eac h ev en t is executed, it ma y spa wn new ev en ts to b e added to the queue. These are

nly

a few instances

f

the t yp es

f

problems for whic h a priorit y queue is a useful to

l.

In terms

f

abstract

p

erations, a priorit y queue is a data structure that tak es elemen ts

f

t yp e value type and implemen ts the follo wing v e

p

erations: void push(value t yp e) add a new v alue to the collection value t yp e & top() return a reference to the largest elemen t in collection void p

p()

delete the largest elemen t from the collection int size() return the n um b er

f

elemen ts in the collection b

l

empt y() return true if the collection is empt y Although the denition sp eaks

f

remo ving the largest v alue, in man y problems the v alue

f

in terest is the smallest item. As w e will see in some

f

the later examples, suc h uses can b e pro vided b y in v erting the comparison test b et w een elemen ts. Note that the name priorit y queue is a misnomer in that the data structure is not a queue, in the sense w e used the term in Chapter 10, since it do es not return elemen ts in a strict rst-in rst-out sequence. Nev ertheless, the name is no w rmly asso ciated with this particular data t yp e.

SLIDE 4 15.1. THE PRIORITY QUEUE D A T A ABSTRA CTION 397 There are at least three

b

vious, but inecien t, w a ys to implemen t a priorit y queue. One approac h w

uld

b e to insert new elemen ts at the fron t

f

a list, th us requiring

nly

constan t time for addition. The generic algorithm max element() can b e used to disco v er the largest elemen t. The max element() algorithm tra v erses the list to nd the largest v alue, requiring O (n) time. Keeping the list

rdered

b y v alue w

uld

mak e for rapid disco v ery

f

the maxim um, but necessitate O (n) time for insertion. Another approac h to implemen ting a priorit y queue is to tak e a collection

f

items and sort them. F rom the sorted collection w e could

btain

not

nly

the largest elemen t, but the next largest, and the next, and so

n.

But as w e ha v e seen, sorting is a relativ ely exp ensiv e

p

eration. F urthermore, it is dicult to insert new v alues in to a sorted collection. Since w e are in terested

nly

in nding the largest elemen t in the collection, w e can emplo y tec hniques that are m uc h more ecien t. In particular, w e will dev elop data structures in whic h w e can nd the largest elemen t in a collection

f

n elemen ts in constan t time, and w e can nd and remo v e the largest elemen t in time prop

rtional

to log n. There is

ne

more metho d that is

b

vious, and not

b

viously inecien t. In Chapter 12 w e examined the STL set data structure. Recall that a new elemen t could b e added to a set in O (log n) steps. If w e rev erse the comparison

p

erator when w e create the set, then the v alue asso ciated with the iterator aSet.b egin() represen ts the largest v alue, and can also b e used to delete this v alue from the collection. A careful examination

f

the iterator pro cedure will sho w that this requires no more than O (log n) steps. Th us, using a set

ne

can p erform b

th

insertions and remo v als in logarithmic time. The reason for rejecting the set is not asymptotic ineciency , but practical realistic ineciency . A set is main taining more information than w e need. W e can dev elop alternativ e data structures that, while they ha v e no b etter asymptotic eciency (they are still O (log n)), generally yield execution times m uc h b etter than w

uld

b e p

ssible

using the set data t yp e. W e will in v estigate t w

data

structures that can b e used to implemen t priorit y queues. The rst is pro vided as a basic data t yp e b y the standard library , while the second will b e dev elop ed indep enden tly . The standard data structure is called a he ap, and main tains the v alues

f

the collection in an arra y . The

p

erations to add

r

remo v e an elemen t to

r

from the heap are relativ ely ecien t, ho w ev er the heap suers from the problem common to man y arra y-based algorithms. This is that the arra y will b e expanded as necessary to the maxim um size, but will not b e made smaller as the heap is reduced. In this fashion the arra y holding the heap will b e the largest size needed to hold the v alues at an y

ne

p

in

t in time. The second data structure, a skew he ap, a v

ids

the maxim um size dicult y b y main- taining the heap v alues in a binary tree. But solving

ne

problem comes

nly

at the cost

f

in tro ducing another, namely the dicult y

f

k eeping the tree relativ ely w ell balanced. Sk ew heaps are in teresting in that the w

rst

case cost for insertions and deletions is a relativ ely slo w O (n), but

ne

can sho w that this w

rst

case b eha vior do es not

ccur

frequen tly and cannot b e sustained. In particular, the

ccurrence
f

a w

rst

case situation m ust necessarily b e follo w ed b y sev eral insertions and deletions that are m uc h faster. Th us, amortized

v

er a n um b er

f

insertions and deletions, the a v erage cost

f
p

eration is still relativ ely go

d.

SLIDE 5 398 CHAPTER 15. PRIORITY QUEUES Another adv an tage

f

the sk ew heap will b e that it pro vides a fast implemen tation for the

p

eration

f

merging t w

priorit

y-queue heaps to form a new queue. 15.2 Heaps A he ap is a binary tree in whic h ev ery no de p

ssesses

the prop ert y that its v alue is larger than

r

equal to the v alue asso ciated with either c hild no de. This is referred to as the he ap

r

der pr

p

erty . A simple induction argumen t establishes that the v alue asso ciated with eac h no de in a heap m ust b e the largest v alue held in the subtree ro

ted

at the no de. It follo ws from this prop ert y that the largest elemen t in a heap will alw a ys b e held b y the ro

t

no de. This is unlik e a searc h tree, where the largest elemen t w as alw a ys held b y the righ tmost no de. Disco v ering the maxim um v alue in a heap is therefore a trivial

p

eration. Recall from Chapter 13 that a c

mplete

binary tr e e is a binary tree that is en tirely lled (in whic h ev ery no de has t w

c

hildren), with the exception

f

the b

ttom

lev el, whic h is lled from left to righ t. Figure 15.1 sho ws a complete binary tree that is also a heap. The k ey insigh t b ehind the heap data structure is the

bserv

ation, whic h w e noted in Chapter 13, that b ecause a complete binary tree is so regular, it can b e represen ted ecien tly in an arra y . The ro

t
f

the tree will b e main tained in p

sition
f

the arra y . The t w

c

hildren

f

no de n will b e held in p

sitions

2n + 1 and 2n + 2. The arra y corresp

nding

to the tree in Figure 15.1 is the follo wing: 16 14 9 10 12 7 8 5 2 11 3 1 2 3 4 5 6 7 8 9 10 Note that a v ector that is sorted largest to smallest is also a heap, but the rev erse is not true. That is, a v ector can main tain a heap and still not b e

rdered.

Giv en the index to a no de, disco v ering either the paren t

r

the c hildren

f

that no de is a simple matter

f

division

r

m ultiplication. No explicit p

in

ters need b e main tained in the arra y structure, and tra v ersals

f

the heap can b e p erformed v ery ecien tly . Notice that the prop ert y

f

completeness is imp

rtan

t to ensure there are no \gaps" in the arra y represen tation. The standard library class p rio rit y queue constructs a heap

n

top

f

a randomly accessible data structure, usually either a vecto r

r

a deque. Lik e the stack and queue data t yp es (Chapter 10), the underlying con tainer is pro vided as a template argumen t. An

ptional

second template argumen t (not sho wn) represen ts the function to b e used in comparing t w

elemen

ts. 1 W e will see an example that uses this argumen t in Section 15.4. T

declare

a priorit y queue, the user m ust state b

th

the priorit y queue t yp e and the t yp e

f

the underlying con tainer, as in the follo wing example: 1 See Section A.3 in App endix A.

SLIDE 6 15.2. HEAPS 399 16

9

X X X X X X z 14

+

Q Q Q Q Q s 10

A

A A U 5 2 12

A

A A U 11 3 9

J

J J ^ 7 8 Figure 15.1: A complete binary tree in heap form // create a priorit y queue

f

in tegers priority queue < vector<int> > aQueue; Figure 15.2 giv es the class declaration and mem b er functions for this data t yp e. Notice that

p

erations are either dened b y the underlying structure,

r

b y

ne
f

the generic heap functions w e will shortly dene. The

p

erations

f

insertion (p erformed b y push(newElement)) and deletion (p erformed b y p

p())

are more complex than the

thers,

and in v

lv

e calling an auxiliary function. W e will deal with insertion rst. When a new elemen t in added to the priorit y queue, it is

b

vious that some v alue m ust b e mo v ed to the end

f

the arra y , to main tain the complete binary tree prop ert y . Ho w ev er, it is lik ely that the new elemen t cannot b e placed there without violating the heap

rder

prop ert y . This violation will

ccur

if the new elemen t is larger than the paren t elemen t for the lo cation. A solution is to place the new elemen t in the last lo cation, then mo v e it in to place b y rep eatedly exc hanging the no de with its paren t no de un til the heap

rder

prop ert y is restored (that is, un til the new no de either rises to the top,

r

un til w e nd a paren t no de that is larger than the new no de). Since the new elemen t rises un til it nds a correct lo cation, this pro cess is sometimes kno wn as a p er c

late

up. The insertion metho d for p ercolating a v alue in to place is sho wn in Figure 15.3. W e ha v e added the in v arian ts required to pro v e the correctness

f

the pro cedure (see sidebar). Since the while lo

p

mo v es up

ne

lev el

f

the tree eac h cycle, it is

b

vious it can iterate no more than log n times. The running time

f

the insertion pro cedure is O (log n). (Note that b efore calling push heap, the new elemen t is pushed

n

to the end

f

the con tainer. F

r

the v ector data structure, this

p

eration could, in the w

rst

case, require O (n) steps, if a new buer is allo cated and elemen ts are copied. This could p

ten

tially increase the execution time

f

the en tire

p

eration.)

SLIDE 7 400 CHAPTER 15. PRIORITY QUEUES // // class priorit y queue // a priorit y queue managed as a v ector heap // template <class Container> class priority queue f public: typedef Container::value type value type; // priorit y queue proto col bool empty () f return c.empty(); g int size () f return c.size(); g value type & top () f return c.front(); g void push (value type & newElement) f c.push back(newElement) ; push heap(c.begin(), c.end()); g void pop () f pop heap (c.begin(), c.end()); c.pop back(); g protected: Container c; // con tainer

f

v alues g; Figure 15.2: Declaration for the class priority queue Heaps and Heaps The term he ap is used for t w

v

ery dieren t concepts in computer science. The heap data structur e is an abstract data t yp e used to implemen t priorit y queues, as w ell as b eing used in a sorting algorithm w e will discuss in a later c hapter. The terms he ap, he ap al lo c ation, and so

n,

are also frequen tly used to describ e memory that is allo cated and released directly b y the user, using the new and delete

p

erators. Y

u

should not confuse the t w

uses
f

the same term.

SLIDE 8 15.2. HEAPS 401 template <class Iterator> void push heap(Iterator start, Iterator stop) // initial condition: // iterator range describ es a heap, except that // nal elemen t ma y b e

ut
f

place f // p

sition

is index

f
ut
f

place elemen t // paren t is index

f

paren t no de unsigned int position = (stop

start)
1;

unsigned int parent = (position

1)

/ 2; // no w p ercolate up while (position > && start[position] < start[parent]) f // in v: tree ro

ted

at p

sition

is a heap swap (start[position ], start[parent]); // in v: tree ro

ted

at paren t is a heap position = parent; parent = (position

1)

/ 2; g // in v: en tire structure is a heap g Figure 15.3: Metho d for insertion in to a heap

SLIDE 9 402 CHAPTER 15. PRIORITY QUEUES Pro

f
f

Correctness: push heap The pro

f
f

correctness for the algorithm named push heap b egins with the assumption that the collection represen ted b y the iterator range represen ts a v alid heap, with the p

ssible

exception

f

the v ery last elemen t, whic h ma y b e

ut
f
rder.

The sole task

f

the algorithm is to mo v e this

ne

elemen t in to place. Throughout the algorithm, the v ariable position will main tain the index p

si-

tion

f

this v alue, while the v ariable parent will main tain the index p

sition
f

the paren t no de. The while lo

p

at the heart

f

the algorithm has t w

test

conditions. Both m ust b e true for the lo

p

to execute. T

gether,

the t w

conditions

assert that the p

sition

has a paren t (that is, the p

sition

is not y et the ro

t

note), and that the paren t v alue is smaller than the p

sition,

in con tradiction to the heap

rder

prop ert y . The follo wing illustrates this situation. 5

@

@ R 9 12 => 5

@

@ R 12 9 The in v arian t at the top

f

the lo

p

b

dy

asserts that the subtree ro

ted

at position represen ts a heap. This will trivially b e true the rst time the while lo

p

is executed, since the subtree represen ts

nly

a leaf. Since the paren t no de is already larger than the

ther

c hild (if the paren t has t w

c

hildren), simply sw apping the p

sition

with the paren t is sucien t to lo cally reestablish the heap

rder

prop ert y . (T

see

wh y , note that an y c hildren

f

no de position m ust ha v e

riginally

b een c hildren

f

no de parent, and m ust therefore b e smaller than the paren t.) F

llo

wing the sw ap, the tree ro

ted

at the index v alue parent will therefore b e a heap. This v alue b ecomes the new p

sition,

and w e determine the new paren t index. The while lo

p

terminates either when the v alue p ercolates all the w a y to the top

f

the heap,

r

when a no de is encoun tered whic h is larger than the new v alue. In the rst case the nal lo

p

in v arian t is asserting that the en tire structure represen ts a heap. If,

n

the

ther

hand, the lo

p

terminates b ecause

f

the second case, w e kno w that the subtree ro

ted

at parent has the heap

rder

prop ert y . But since this subtree holds the

nly

v alue that could ha v e b een

ut
f
rder,

w e therefore can conclude that the en tire structure m ust ha v e the heap

rder

prop ert y .

SLIDE 10 15.2. HEAPS 403 14

9

X X X X X X z 3

+

J J J ^ 10

A

A A U 5 2 12

A

A A U 11 16 9

J

J J ^ 7 8 Figure 15.4: A v alue p ercolating do wn in to p

sition.

The deletion pro cedure is handled in a manner similar to insertion. W e sw ap the last p

sition

in to the rst lo cation. Since this ma y destro y the heap

rder

prop ert y , the elemen t m ust p er c

late

down to its prop er p

sition

b y exc hanging places with the larger

f

its c hildren. F

r

reasons that will shortly b ecome clear, w e in v

k

e another routine named adjust heap to do this task. 2 Figure 15.4 sho ws an in termediate step in this pro cess. The v alue 3 has b een promoted to the ro

t

p

sition,

where it has subsequen tly b een sw app ed with the larger

f

its t w

c

hildren. The v alue 3 will no w b e compared to the v alues 10 and 12, and will b e sw app ed with the larger v alue. This will con tin ue un til either the v alue is larger than b

th

c hildren,

r

un til w e reac h the leaf lev el

f

the tree. The co de to p erform deletion is sho wn in Figure 15.5. Since at most three comparisons

f

data v alues are p erformed at eac h lev el, and the while lo

p

traces

ut

a path from the ro

t
f

the tree to the leaf, the complexit y

f

the deletion pro cedure is also O (log n). 15.2.1 Application { Heap Sort The heap data structure pro vides an elegan t tec hnique for sorting an arra y . The basic idea is to rst form the arra y in to a heap. T

sort

the arra y , the top

f

the heap (the largest elemen t) is sw app ed with the last elemen t

f

the arra y , and the size

f

the heap is reduced b y

ne.

The eect

f

the sw ap, ho w ev er, ma y b e to destro y the heap prop ert y . But this is exactly the same condition w e encoun tered in deleting an elemen t from the heap. And, not surprisingly , w e can use the same solution. Heap

rder

is restored b y in v

king

the adjust heap pro cedure. 2 The pro cedure adjust heap is not dened b y the standard library , and is therefore not guaran teed to exist in all implemen tations.

SLIDE 11 404 CHAPTER 15. PRIORITY QUEUES template <class Iterator> void pop heap (Iterator start, Iterator stop) f unsigned int lastPosition = (stop

start)
1;

// mo v e the largest elemen t in to the last lo cation swap (start[0], start[lastPositi

n

]) ; // then readjust adjust heap(start, lastPosition, 0); g template <class Iterator> void adjust heap (Iterator start, unsigned heapSize, unsigned position) // initial conditions: // collection represen ts a heap, except that elemen t // at index v alue p

sition

ma y b e

ut
f
rder

f while (position < heapsize) f // T

x,

replace p

sition

with the larger //

f

the t w

c

hildren unsigned int childpos = position

2

+ 1; if (childpos < heapsize) f if ((childpos + 1 < heapsize) && start[childpos + 1] > start[childpos]) childpos++; // c hildp

s

is larger

f

t w

c

hildren if (start[position] > start[childpos]) // structure is no w heap return; else swap (start[position], start[childpos]) ; g position = childpos; g g Figure 15.5: Metho d for deletion from a heap

SLIDE 12 15.2. HEAPS 405 Pro

f
f

Correctness: adjust heap The adjust heap algorithm is in some w a ys the

pp
site
f

the push heap pro cedure. Here, the assumption is that the structure

f

the giv en size b eginning at the starting iterator is a heap, except that the v alue with the index v alue position ma y b e

ut
f
rder.

T

reestablish

the heap

rder

prop ert y , the t w

c

hildren

f

no de position are examined. The v alue indexed b y childpos is set to the larger

f

the t w

c

hildren. If this v alue is smaller than the v alue in question, then the heap

rder

prop ert y do es in fact hold, and therefore the en tire structure m ust b e a heap. If,

n

the

ther

hand, the larger c hild is also larger than the v alue in question, then they m ust b e sw app ed. This is illustrated in the follo wing picture: 12

@

@ R 5 9 => 5

@

@ R 12 9 Note that since the elemen t w as sw app ed with the larger

f

the t w

c

hildren, the new ro

t

m ust therefore b e not

nly

larger than the elemen t in question, but also larger than the smaller c hild. Th us w e need not consider the subtree ro

ted

at the smaller c hild. But it is no w necessary to con tin ue to examine the subtree ro

ted

at the p

sition

in to whic h the v alue in question w as sw app ed. The larger c hild p

sition

b ecomes the new v alue held b y the v ariable position, and the while lo

p

con tin ues. The algorithm terminates either when the v alue in question nds its lo cation (b eing larger than b

th

c hildren),

r

it reac hes a p

in

t where it has no c hildren. Sligh tly more surprising is that w e can use the adjust heap pro cedure to construct an initial heap from an unorganized collection

f

v alues held in a v ector. T

see

this, note that a subtree consisting

f

a leaf no de b y itself satises the heap

rder

prop ert y . T

build

the initial heap, w e start with the smallest subtree con taining in terior no des, whic h corresp

nds

to the middle

f

the data arra y . In v

king

the adjust heap metho d for this v alue will ensure the subtree satises the heap

rder

prop ert y . W alking bac k to w ards the ro

t
f

the tree, w e rep eatedly in v

k

e the adjust heap, thereb y ensuring all subtrees are themselv es heaps. When w e nally reac h the ro

t,

the en tire tree will ha v e b een made in to a heap. This algorithm is implemen ted b y the follo wing pro cedure: template <class Iterator>

SLIDE 13 406 CHAPTER 15. PRIORITY QUEUES Pro

f
f

Correctness: mak e heap T

pro

v e that the mak e heap algorithm creates a heap it is necessary to under- stand the task b eing p erformed b y the lo

p

that is at the heart

f

the algorithm. A t eac h step

f

this algorithm, the assumption is that the subtrees represen ting the c hildren

f

no de i are prop er heaps, and the task to b e p erformed is to mak e the subtree ro

ted

at no de i in to a heap. Note that the v alue i is initialized to the v alue heapSize / 2, and mo v es do wn- w ards. Observ e that all subtrees with index v alues larger than heapSize / 2 represen t leaf no des, and that leaf no des p

ssess

the heap prop ert y (trivially , since they ha v e no c hildren). Th us, the rst time execution mo v es from the start

f

the pro cedure to the assertion in the b

dy
f

the lo

p,

the assertions m ust b e true. W e ha v e already pro v en the adjust heap pro cedure, and therefore the in v arian t follo wing the pro cedure call m ust b e true. No w consider the case where w e encoun ter the assertion at the b eginning

f

the lo

p

b

dy

, after ha ving executed some n um b er

f

previous iterations

f

the lo

p.

In this case, the c hildren

f

no de i m ust either b e lea v es,

r

they m ust ha v e b een previously pro cessed. In either case, the subtrees ro

ted

at the c hild no des m ust b e heaps, and therefore follo wing execution

f

the b

dy
f

the lo

p,

the subtree ro

ted

at no de i m ust b e a heap. The establish the nal condition, w e simply note that either the lo

p

w as executed, in whic h case the nal condition matc hes

ne
f

the lo

p

in v arian ts w e previously established,

r

the lo

p

w as nev er executed, whic h can

nly

happ en if the heap con tains

nly

a single leaf. In the latter case, w e ha v e already noted that a leaf no de is a heap. void make heap (Iterator start, Iterator stop) f unsigned int heapSize = stop

start;

for (int i = heapSize / 2; i >= 0; i--) // assume c hildren

f

no de i are heaps adjust heap(start, heapSize, i); // in v: tree ro

ted

at no de i is a heap // assert: structure is no w a heap g T

con

v ert a heap in to a sorted collection, w e simply rep eatedly sw ap the rst and last p

sitions,

then readjust the heap prop ert y , reducing the heap size b y

ne

elemen t. This is p erformed b y the follo wing pro cedure:

SLIDE 14 15.2. HEAPS 407 template <class Iterator> void sort heap (Iterator start, Iterator stop) f unsigned int lastPosition = stop

start
1;

while (lastPosition > 0) f swap(start[0], start[lastPositio n]) ; adjust heap(start, lastPosition, 0); lastPosition--; g g Com bining these t w

,

the heap sort algorithm can b e written as follo ws: 3 template <class Iterator> void heap sort(Iterator start, Iterator stop) f // sort the v ector argumen t using a heap algorithm // rst build the initial heap make heap (start, stop); // then con v ert heap in to sorted collection sort heap (start, stop); g T

deriv

e the asymptotic running time for this algorithm, recall w e noted that the adjust heap pro cedure requires O (log n) steps. There are n executions

f

adjust heap to generate the initial heap, and n further executions to reheap v alues during the sorting

p

eration. Com bining these tells us that the total running time is O (n log n). This matc hes that

f

the merge sort algorithm (Section 8.3.3) and the quic k sort algorithm (Section 14.5.1), and is b etter than the O (n 2 ) bubble and insertion sort algorithms (Section 5.1.4). Of a more practical b enet, note that the heap sort algorithm do es not require an y additional space, since it constructs the heap directly in the v ector input v alue. This w as not true

f

some

f

the previous sorting algorithms w e ha v e seen. Those algorithms m ust pa y the cost not

nly
f

the sorting itself, but

f

the allo cation and deallo cation

f

the data structures formed during the pro cess

f
rdering

the elemen ts. An empirical analysis

f

the running time

f

the heap sort algorithm illustrates that for almost all v ector sizes heapsort is comparable in sp eed to quic k sort. An adv an tage

f

heap sort

v

er quic k sort is that the heap sort algorithm is less inuenced b y the initial 3 Note that make heap and sort heap are generic algorithms in the standard library , but heap sort is not.

SLIDE 15 408 CHAPTER 15. PRIORITY QUEUES 2 4 6 8 10 2000 4000 6000 8000 10000 12000 14000 elemen ts in input v ector heap sort quic k sort Figure 15.6: Empirical Timing

f

heap sort distribution

f

the input v alues. Y

u

will recall that a p

r

distribution

f

v alues can mak e quic k sort exhibit O (n 2 ) b eha vior, while heap sort is O (n log n) in all circumstances. 15.3 Sk ew Heaps

The
b

vious metho d to a v

id

the b

unded-size

problem

f

heaps is to use a tree represen tation. This is not, ho w ev er, quite as simple as it migh t seem. The k ey to

btaining

logarithmic p erformance in the heap data structure is the fact that at eac h step w e w ere able to guaran tee the tree w as completely balanced. Finding the next lo cation to b e lled in an arra y represen tation

f

a completely balanced binary tree is trivial; it is simply the next lo cation follo wing the curren t top

f

the arra y . In a tree form this is not quite as easy . Consider the tree sho wn in Figure 15.1 (page 399). Kno wing the lo cation

f

the last elemen t (the v alue 3) is

f

no help in disco v ering where the next elemen t should b e inserted in

rder

to main tain the balanced binary tree prop ert y . In fact, the next elemen t is part

f

an en tirely dieren t subtree than that con taining the curren t last elemen t. A skew he ap a v

ids

this problem b y making no attempt to main tain the heap as a completely balanced binary tree. As w e sa w when w e examined searc h trees, this means that a tree can p

ten

tially b ecome almost linear, and w e can place no guaran tee

n

logarithmic

Section

headings follo w ed b y an asterisk indicate

ptional

material.

SLIDE 16 15.3. SKEW HEAPS

409

p erformance for an y individual

p

eration. But there is another critical

bserv

ation w e can mak e concerning heaps, whic h is that the

rder
f

the left and righ t c hildren for an y no de is essen tially arbitrary . W e can exc hange the left and righ t c hildren

f

an y no de in a heap without destro ying the heap

rder

prop ert y . W e can mak e use

f

this

bserv

ation b y systematically sw apping the left and righ t c hildren

f

a no de as w e p erform insertions and deletions. A badly un balanced tree can aect the p erformance

f
ne
p

eration, but it can b e sho wn that subsequen t insertions and deletions m ust as a consequence b e v ery rapid. In fact, if m insertions

r

deletions are p erformed, it can b e sho wn (although the details are b ey

nd

the discussion here) that the total time to p erform all m

p

erations is b

unded

b y O (m log n). Th us, amortize d

v

er time, eac h

p

eration is no w

rse

than O (log n). The second

bserv

ation critical to the implemen tation

f

sk ew heaps is that b

th

insertions and deletions can b e considered as sp ecial cases

f

merging t w

trees

in to a single heap. This is

b

vious in the case

f

the deletion pro cess. Remo ving the ro

t
f

the tree results in t w

subtrees.

The new heap can b e constructed b y simply merging these t w

c

hild trees. template <class value type> void skewHeap<value type>::pop () // remo v e the minim um elemen t from a sk ew heap f assert (! empty()); node<value type>

top

= root; root = merge(root->right (), root->left()); delete top; g Similarly , insertion can b e considered a merge

f

the existing heap and a new heap con taining a single elemen t. template <class value type> void skewHeap<value type>::push (value type & val) // to add a new v alue, simply merge with // a tree con taining

ne

no de f root = merge(root, new node<value type>(val)); g The skewHeap data structure, sho wn in Figure 15.7, implemen ts b

th

insertions and deletions using an in ternal metho d merge. The recursiv e merge

p

eration is sho wn b elo w. If either argumen t is empt y , then the result

f

a merge is simply the

ther

tree. Otherwise w e will assume the largest v alue is the ro

t
f

the rst tree, b y returning the merge

f

the argumen ts rev ersed if this is not the case. T

p

erform the merge, w e mo v e the curren t left c hild

f

the left argumen t to the righ t c hild

f

the result, and recursiv ely merge the righ t argumen t with the

ld

righ t c hild.

SLIDE 17 410 CHAPTER 15. PRIORITY QUEUES // // class sk ewHeap // heap priorit y queue implemen ted using sk ew heap merge //

p

erations // template <class value type> class skewHeap f public: // constructors skewHeap () : root(0) f g skewHeap (); // priorit y queue proto col bool empty () f return root == 0; g int size () f return root->size(); g value type & top () f return root->value; g void pop (); void push (value type & value); // additional metho d: splice t w

heaps

together void splice (skewHeap & secondHeap); protected: // ro

t
f

heap node<value type>

root;

// in ternal metho d to merge t w

heaps

node<value type>

merge

(node<value type> , node<value type> ); g; Figure 15.7: The skewHeap class declaration

SLIDE 18 15.3. SKEW HEAPS

411

template <class value type> node<value type>

skewHeap<value

type>::merge (node<value type>

h1,

node<value type>

h2)

// merge t w

sk

ew heaps to form a new heap f // if either tree is empt y , return the

ther

if (! h1) return h2; if (! h2) return h1; // assume largest is ro

t
f

h1 if (h2->value > h1->value) return merge(h2, h1); // rev erse c hildren and recurse node<value type>

lchild

= h1->left(); if (lchild) f h1->left(merge( h1- >r igh t( ), h2)); h1->right(lchil d); g else // no left c hild h1->left(h2); return h1; g F

r

example, supp

se

w e are merging a heap con taining the elemen ts 2, 5 and 7 with a heap con taining the t w

elemen

ts 4 and 6. Since the elemen t at the top

f

the left heap, 7, is larger it b ecomes the new ro

t.

A t the same time the

ld

left c hild

f

the ro

t

b ecomes the new righ t c hild. T

form

the new righ t c hild w e recursiv ely merge the

ld

righ t c hild and the

riginal

righ t argumen t. 5

7

@ @ R 2 mer g e ! 6

4

) 2 mer g e ! 4

6

7 @ @ R 5 The rst step in the recursiv e call is to ip the argumen ts, so that the largest elemen t is held in the rst argumen t. The top elemen t

f

this heap then b ecomes the new ro

t.

As b efore, the

ld

left c hild

f

this v alue b ecomes the new righ t c hild. A recursiv e call is made

SLIDE 19 412 CHAPTER 15. PRIORITY QUEUES Merging Heaps The fact that sk ew heaps basically

p

erate b y merging t w

heaps

to form a new heap means that it is relativ ely easy to com bine together t w

instances
f

the data structure. W e ha v e tak en adv an tage

f

this b y pro viding a splice metho d that tak es another instance

f

sk ew heap as argumen t. template <class value type> void skewHeap<value type>::splice (skewHeap<value type> & secondHeap) f // merge elemen ts from a second heap in to curren t heap root = merge(root, secondHeap.root); // empt y v alues from second heap secondHeap.root = 0; g The merge pro cedure used is the same as the merge used in implemen ting the addition and remo v al metho ds, and can th us b e exp ected to run v ery rapidly , in time prop

rtional

to the longest path in the largest heap, not the n um b er

f

elemen ts in the argumen t heap, as w

uld

b e the case

f

the v alues w ere simply added

ne

b y

ne.

An imp

rtan

t feature to note, ho w ev er, is that this

p

eration eectiv ely empties the argumen t heap, b y setting its ro

t

v alue to zero. The reason wh y this is necessary has to do with the w a y in whic h

ur

data structures are p erforming memory managemen t. In

ur

sc heme, eac h no de in a tree m ust b e \o wned" b y

ne

and

nly
ne

data structure. This data structure is resp

nsible

for p erforming a deletion to free up the memory used b y the no de when it is no longer b eing used as part

f

the structure. If a single no de w ere to b e used in t w

dieren

t structures it is p

ssible,

indeed inevitable, that it w

uld

b e deleted at t w

dieren

t times b y t w

dieren

t structures.

SLIDE 20 15.3. SKEW HEAPS

413

to insert the righ t argumen t, 7, in to the no w empt y former righ t c hild

f

the no de 4. This results in the no de 7 b eing returned, and the nal result pro duced. 6

4

mer g e ! 2 7 @ @ R 5 ) 2

6

@ @ R 4

7

@ @ R 5 T

illustrate

wh y the amortized analysis

f

sk ew heaps can b e so go

d,

note that the w

rst

case situation

ccurs

when the left subtree con tains a long path along the righ t c hild links. F

r

example consider the merging the singleton 2 in to suc h a tree. 8

9

@ @ R 7

@

@ R 6 5

@

@ R 4 3 2 mer g e ! ) 6

7

@ @ R 5

4

@ @ R 3 mer g e ! 2 9 @ @ R 8 4

5

@ @ R 3 mer g e ! 2 7 @ @ R 6

9

@ @ R 8 ) 2

3
5

@ @ R 4

7

@ @ R 6

9

@ @ R 8 The merge requires 4 steps. Ho w ev er, note that no w the long righ t path has b een con v erted in to a long left path. Th us, the next insertion will b e relativ ely quic k. Assume, for example, w e no w insert the v alue 1.

SLIDE 21 414 CHAPTER 15. PRIORITY QUEUES 2

3
5

@ @ R 4

7

@ @ R 6 9 @ @ R

8
1

It is tempting to conjecture that after t w

insertions

w e w

uld

b e bac k to the

riginal

p

r

conguration. But note that this has not

ccurred.

The longest path is still a left path, although it is no w

n

the righ t side. It will b e quite a few steps b efore the situation can arise where a long righ t path can slo w insertions. 15.4 Application { Discrete Ev en t-Driv en Sim ulation Imagine y

u

are thinking ab

ut
p

ening an ice cream store

n

a p

pular

b eac h lo cation. Y

u

need to decide ho w large the store should b e; ho w man y seats y

u

should ha v e and so

n.

If y

u

plan to

small,

customers will b e turned a w a y when there is insucien t space and y

u

will lose prots. On the

ther

hand if y

u

plan to

large,

most

f

the seats will b e un used and y

u

will b e pa ying useless ren t

n

the space, and hence losing prots. So y

u

need to c ho

se

appro ximately the righ t n um b er { but ho w do y

u

decide? One approac h w

uld

b e to p erform a sim ulation. Y

u

rst examine similar

p

erations in comparable lo cations, and form a mo del whic h includes, among

ther

factors, an estimation

f

the n um b er

f

customers y

u

can exp ect to arriv e in an y p erio d

f

time, the length

f

time they will tak e to decide up

n

an

rder,

and the length

f

time they will sta y after ha ving b een serv ed. Based

n

this y

u

can design a sim ulation. A discr ete event-driven simulation is a p

pular

sim ulation tec hnique. Ob jects in the sim ulation mo del

b

jects in the real w

rld,

and are programmed to react as m uc h as p

ssible

as the real

b

jects w

uld

react. A priorit y queue is used to store a represen tation

f

\ev en ts" that are w aiting to happ en. This queue is stored in

rder

based

n

the time the ev en t should

ccur,

so the smallest elemen t will alw a ys b e the next ev en t to b e mo deled. As an ev en t

ccurs,

it can spa wn

ther

ev en ts. These subsequen t ev en ts are placed in to the queue as w ell. Execution con tin ues un til all ev en ts ha v e

ccurred,
r

un til a preset time for the sim ulation is exceeded. T

see

ho w w e migh t design a sim ulation

f
ur

ice cream store, consider a t ypical scenario. A group

f

customers arriv e at the ice cream store. F rom

ur

measuremen ts

f

similar stores w e deriv e a probabilit y that indicates ho w frequen tly this

ccurs.

F

r

example supp

se

w e assume that groups will consist

f

from 1 to 5 p eople, selected uniformly

v

er that

SLIDE 22 15.4. APPLICA TION { DISCRETE EVENT-DRIVEN SIMULA TION 415 range. (In actual sim ulations the distribution w

uld

seldom b e uniform. F

r

example groups

f

size 2 and 3 migh t predominate, with groups

f

size 1 and groups larger than 3 b eing relativ ely less frequen t. The mathematics in v

lv

ed in forming non-uniform distributions is subtle, and not particularly relev an t to

ur

discussion. W e will therefore use uniform distributions throughout.) These groups will arriv e at times spaced from 1 to 10 min utes apart, again selected uniformly . Once they arriv e, a group will either b e seated,

r

see that there are no seats and lea v e. If seated they will tak e from 2 to 10 min utes to

rder,

and

nce

they

rder

they will remain from 15 to 35 min utes in the store. W e kno w that ev ery customer will

rder

from 1 to 3 sco

ps
f

ice cream, and that the store mak es a prot

f

$0.35

n

eac h sco

p.

T

create

a random in teger b et w een t w

v

alues w e can write a simple function that uses the randomInteger class w e in tro duced in Chapter 2. This new function tak es the in teger endp

in

ts, and returns a new v alue from a uniform distribution b et w een the t w

p
in

ts: integer randBetween (integer low, integer high) // return random in teger b et w een lo w and high f randomInteger randomizer; return low + randomizer(high

low);

g The primary

b

ject in the sim ulation is the store itself. It migh t seem

dd

to pro vide \b eha vior" for an inanimate

b

ject suc h as a store, ho w ev er w e can think

f

the store as a useful abstraction for the serv ers and managers who w

rk

in the store. The store manages t w

data

items; the n um b er

f

a v ailable seats and the amoun t

f

prot generated. The b eha vior

f

the store can b e describ ed b y the follo wing list:

When

a customer group arriv es, the size

f

the group is compared to the n um b er

f

seats. If insucien t seats are a v ailable the group lea v es. Otherwise the group is seated and the n um b er

f

seats decreased.

When

a customer

rders

and is serv ed the amoun t

f

prot is computed.

When

a customer group lea v es the seats are released for another customer group. A class description for IceCreamStore is sho wn in Figure 15.8. The implemen tation

f

the metho ds are sho wn in Figure 15.9. A F ramew

rk

for Sim ulations Rather than simply co de a sim ulation

f

this

ne

problem, w e will generalize the problem and rst pro duce a generic fr amework for sim ulations. This is similar to the framew

rk

for bac ktrac king problems w e presen ted in Chapter 10.

SLIDE 23 416 CHAPTER 15. PRIORITY QUEUES class IceCreamStore f public: IceCreamStore() : freeChairs(35), profit(0.0) f g bool canSeat (unsigned int numberOfPeople); void

rder(unsigned

int numberOfScoops); void leave(unsigned int numberOfPeople); unsigned int freeChairs; double profit; g; Figure 15.8: The class IceCreamStore. A t the heart

f

a sim ulation is the concept

f

an event. An ev en t will b e represen ted b y an instance

f

class event. The

nly

v alue held b y the class will b e the time the ev en t is to

ccur.

The metho d processEvent will b e in v

k

ed to \execute" the ev en t when the appropriate time is reac hed. // // class ev en t // execution ev en t in a discrete ev en t driv en sim ulation // class event f public: // constructor requires time

f

ev en t event (unsigned int t) : time(t) f g // time is a public data eld unsigned int time; // execute ev en t b y in v

king

this metho d virtual void processEvent() f g g; The sim ulation queue will need to main tain a collection

f

dieren t t yp es

f

ev en ts. Eac h dieren t form

f

ev en t will b e represen ted b y a dieren t deriv ed classes

f

class event. Not all ev en ts will ha v e the same t yp e, although they will all b e deriv ed from class event.

SLIDE 24 15.4. APPLICA TION { DISCRETE EVENT-DRIVEN SIMULA TION 417 bool IceCreamStore::c an Sea t (unsigned int numberOfPeople) // if sucien t ro

m,

then seat customers f cout << "Time: " << time; cout << " group

f

" << numberOfPeople << " customers arrives"; if (numberOfPeople < freeChairs) f cout << " is seated" << endl; freeChairs

=

numberOfPeople; return true; g else f cout << " no room, they leave" << endl; return false; g g void IceCreamStore::o rd er (unsigned int numberOfScoops) // serv e ice-cream, compute prots f cout << "Time: " << time; cout << " serviced

rder

for " << numberOfScoops << endl; profit += 0.35

numberOfScoops;

g void IceCreamStore::l ea ve (unsigned int numberOfPeople) // p eople lea v e, free up c hairs f cout << "Time: " << time; cout << " group

f

size " << numberOfPeople << " leaves" << endl; freeChairs += numberOfPeople; g Figure 15.9: The metho ds implemen ting the class IceCreamStore.

SLIDE 25 418 CHAPTER 15. PRIORITY QUEUES P

lymorphic

V ariables A v ariable that can hold man y dieren t typ es

f

v alues is called p

lymorphic

(p

ly

= man y , morph = form). In

b

ject-orien ted languages, suc h as C++, p

lymorphic

v ariables are link ed to the class-deriv ed class hierarc h y . A v ariable declared as a p

in

ter to a paren t class, suc h as the class event, can in fact hold a v alue that is a deriv ed class t yp e, suc h as a rriveEvent. In C++ p

lymorphic

v ariables can

nly
ccur

through the use

f

p

in

ters

r

references. This is due to the w a y memory is allo cated b y the C++ system. Note that the storage required b y the c hild class is lar ger than the storage required b y the paren t class. (The paren t class had

nly
ne

in teger data eld, while the c hild class has t w

).

Memory for all elemen ts

f

a ve ctor m ust b e the same{this is necessary for the ecien t indexing abilit y c haracteristic

f

v ectors. These t w

requiremen

ts conict with

ne

another. Ho w ev er, the space required to hold a p

in

ter is xed, regardless

f

the t yp e

f

v alue it p

in

ts to. It is for this reason that C++

nly

allo ws p

in

ter v alues to b e p

lymorphic.

(This is sometimes called a heter

gene
us

collection, and the v alue that p

in

ts to an ev en t is sometimes called a p

lymorphic

v ariable.) F

r

this reason the collection m ust store p

inters

to ev en ts, instead

f

the ev en ts themselv es. Since comparison

f

p

in

ters cannot b e sp ecialized

n

the basis

f

the p

in

ter t yp es, w e m ust instead dene an explicit comparison function for p

in

ters to ev en ts. When using the standard library this is accomplished b y dening a new structure, the sole purp

se
f

whic h is to dene the function in v

cation
p

erator (the ()

p

erator) in the appropriate fashion. Since in this particular example w e wish to use the priorit y queue to return the smal lest elemen t eac h time, rather than the largest, the

rder
f

the comparison is rev ersed, as follo ws: class eventComparison f public: bool

perator

() (event

left,

event

right)

f return left->time > right->time; g g; W e are no w ready to dene the class simulation, whic h pro vides the basic structure for the sim ulation activities. The class simulation pro vides t w

basic

functions. The rst is used to insert a new ev en t in to the queue, while the second runs the sim ulation. A data eld is also pro vided to hold the curren t sim ulation \time".

SLIDE 26 15.4. APPLICA TION { DISCRETE EVENT-DRIVEN SIMULA TION 419 class simulation f public: simulation () : eventQueue(), currentTime(0) f g void scheduleEvent (event

newEvent)

f eventQueue.push (newEvent); g void run(); unsigned int currentTime; protected: priority queue<vector<even t >, eventComparison> eventQueue; g; Notice the declaration

f

the priorit y queue used to hold the p ending ev en ts. In this case w e are using a v ector as the underlying con tainer. W e could just as easily ha v e used a deque. Note also the w a y in whic h the comparison function class is pro vided as the second template argumen t. The heart

f

the sim ulation is the mem b er function run(), whic h denes the ev en t lo

p.

This pro cedure mak es use

f

three

f

the v e priorit y queue

p

erations, namely top(), pop(), and empty(). It is implemen ted as follo ws: void simulation::run( ) // execute ev en ts un til ev en t queue b ecomes empt y f while (! eventQueue.empt y() ) f event

nextEvent

= eventQueue.top(); eventQueue.pop( ); time = nextEvent->time; nextEvent->proc ess Ev ent () ; delete nextEvent; g g Ice Cream Store Sim ulation Ha ving created a framew

rk

for sim ulations in general, w e no w return to the sp ecic sim u- lation in hand, the ice cream store. An instance

f

class simulation is dened as a global v ariable, called theSimulation. An instance

f

iceCreamStore is accessible via the name theStore.

SLIDE 27 420 CHAPTER 15. PRIORITY QUEUES As w e noted already , eac h activit y is matc hed b y a deriv ed class

f

event. Eac h deriv ed class

f

event includes an in teger data eld, whic h represen ts the size

f

a group

f

customers. The arriv al ev en t

ccurs

when a group en ters. When executed, the arriv al ev en t creates and installs a new

rder

ev en t: class arriveEvent : public event f public: arriveEvent (unsigned int time, unsigned int gs) : event(time), groupSize(gs) f g virtual void processEvent (); protected: unsigned int groupSize; g; void arriveEvent::pro ce ssE ve nt( ) f if (theStore.canSea t(g ro upS iz e)) theSimulation.s che du leE ve nt (new

rderEvent(time

+ randBetween(2,1 0) , groupSize)); g An

rder

ev en t similarly spa wns a lea v e ev en t: class

rderEvent

: public event f public:

rderEvent

(unsigned int time, unsigned int gs) : event(time), size(gs) f g virtual void processEvent (); protected: unsigned int groupSize; g; void

rderEvent::proc

es sEv en t() f // eac h p erson

rders

some n um b er

f

sco

ps

for (int i = 0; i < groupSize; i++) theStore.order( 1 + rand(3)); theSimulation.sch ed ule Ev ent (new leaveEvent(time + randBetween(15,35 ), groupSize)); g; Finally , lea v e ev en ts free up c hairs, but do not spa wn an y new ev en ts:

SLIDE 28 15.4. APPLICA TION { DISCRETE EVENT-DRIVEN SIMULA TION 421 class leaveEvent : public event f public: leaveEvent (unsigned int time, unsigned int gs) : event(time), groupSize(gs) f g virtual void processEvent (); protected: unsigned int groupSize; g; void leaveEvent::proc es sEv en t () f theStore.leave(gr

u

pSi ze ); g The main program simply creates a certain n um b er

f

initial ev en ts, then sets the simulation in motion. In

ur

case w e will sim ulate t w

hours

(120 min utes)

f
p

eration, with groups arriving with random distribution b et w een 2 and 5 min utes apart. void main() f // load queue with some n um b er

f

initial ev en ts unsigned int t = 0; while (t < 120) f t += randBetween(2,5 ); theSimulation.s che du leE ve nt( ne w arriveEvent(t, randBetween(1,5)) ); g // then run sim ulation and prin t prots theSimulation.run () ; cout << "Total profits " << theStore.profit << endl; g An example execution migh t pro duce a log suc h as the follo wing: customer group

f

size 4 arrives at time 11 customer group

f

size 4

rders

5 scoops

f

ice cream at time 13 customer group size 4 leaves at time 15 customer group

f

size 2 arrives at time 16 customer group

f

size 1 arrives at time 17 customer group

f

size 2

rders

2 scoops

f

ice cream at time 19 customer group

f

size 1

rders

1 scoops

f

ice cream at time 19 customer group size 1 leaves at time 22

SLIDE 29 422 CHAPTER 15. PRIORITY QUEUES ... customer group

f

size 2

rders

3 scoops

f

ice cream at time 136 customer group size 2 leaves at time 143 total profits are 26.95 15.5 Chapter Summary A priorit y queue is not a queue at all, but is a data structure designed to p ermit rapid access and remo v al

f

the largest elemen t in a collection. Priorit y queues can b e structured b y building them

n

top

f

lists, sets, v ectors

r

deques. The v ector

r

deque v ersion

f

a priorit y queue is called a heap. The heap structure forms the basis

f

a v ery ecien t sorting algorithm. A sk ew heap is a form

f

heap that do es not ha v e the xed size c haracteristic

f

the v ector heap. The sk ew heap data structure is in teresting in that it can p

ten

tially ha v e a v ery p

r

w

rst

case p erformance. Ho w ev er, it can b e sho wn that the w

rst

case p erformance cannot b e main tained, and follo wing an y

ccurrence

the next sev eral

p

erations

f

insertion

r

remo v al m ust b e v ery rapid. Th us, when measured

v

er sev eral

p

erations the p erformance

f

a sk ew heap is v ery impressiv e. A common problem addressed using priorit y queues is the idea

f

discrete ev en t-driv en sim ulation. W e ha v e illustrated the use

f

heaps in an example sim ulation

f

an ice-cream store. In Chapter 19 w e will

nce

more use a priorit y queue in the dev elopmen t

f

an algorithm for computing the shortest path b et w een pairs

f

p

in

ts in a graph. Key Concepts

Priorit

y Queue

Heap
Heap
rder

prop ert y

Heap

sort

Sk

ew heap

Discrete

ev en t driv en sim ulation References The binary heap w as rst prop

sed

b y John Williams in conjunction with the heapsort algorithm [Williams 64 ]. Although heapsort is no w considered to b e

ne
f

the standard classic algorithms, a thorough theoretical analysis

f

the algorithm has pro v en to b e surprisingly

SLIDE 30 15.5. CHAPTER SUMMAR Y 423 dicult. It w as

nly

in 1991 that the b est case and a v erage case execution time analysis

f

heapsort w as rep

rted

[Sc haer 91 ]. Sk ew heaps w ere rst describ ed b y Donald Sleator and Rob ert T arjan in [Sleator 86 ]. An explanation

f

the amortized analysis

f

sk ew heaps is presen ted in [W eiss 92 ]. The ice cream store sim ulation is deriv ed from a similar sim ulation in m y earlier b

k
n

Smalltalk [Budd 87 ]. Study Questions 1. What is the primary c haracterization

f

a priorit y queue? 2. Wh y is a priorit y queue not a true queue? 3. Ho w could a priorit y queue b e constructed using a list? 4. What is the heap data structure? 5. What are the t w

most

common uses

f

the term heap in computer science? 6. What is the heap

rder

prop ert y? 7. What is a complete binary tree? 8. Giv e a v ector

f

ten elemen ts

rdered

largest to smallest, then sho w the corresp

nding

complete binary tree. Wh y will the tree alw a ys b e a heap? 9. What is the dierence b et w een the pro cedures sort heap and heap sort? 10. In the sk ew heap data structure, what is similar ab

ut

the push and pop routines? 11. What is a discrete ev en t-driv en sim ulation? 12. What is a heterogeneous collection? 13. What is a p

lymorphic

v ariable? Exercises 1. Complete the design

f

a priorit y queue constructed using lists. That is, dev elop a data structure with the same in terface as the priority queue data t yp e, but whic h uses lists as the underlying con tainer and implemen ts the in terface using list

p

erations. 2. While it is p

ssible

to implemen t iterators for the heap data structure, argue wh y it mak es little sense to do so. 3. Giv e an example

f

a priorit y queue that

ccurs

in a non-computer science situation.

SLIDE 31 424 CHAPTER 15. PRIORITY QUEUES 4. Explain ho w the skewHeap data structure could b e c hanged so that the smallest item w as the v alue most easily accessible, instead

f

the largest v alue. 5. Sho w what a heap data structure lo

ks

lik e subsequen t to insertions

f

eac h

f

the follo wing v alues: 4 2 5 8 3 6 1 10 14 6. Sho w what a sk ewHeap data structure lo

ks

lik e subsequen t to insertions

f

eac h

f

the follo wing v alues: 4 2 5 8 3 6 1 10 14 7. Consider the follo wing alternativ e implemen tation

f

push heap: template <class Iterator> void push heap (Iterator start, Iterator stop) f unsigned int heapsize = stop

start;

unsigned int position = heapsize

1;

// no w restore the p

ssibly

lost heap prop ert y while (position > 0) f // reheap the subtree adjust heap(data, heapsize, position); // mo v e up the tree position = (position-1)/2; g g (a) Pro v e that this algorithm will in fact successfully add a new elemen t to the heap. (b) Explain wh y as a practical matter this algorithm is less desirable than the algorithm presen ted in the text. 8. Using the tec hniques describ ed in Problem 4.3, Chapter 4 (page 86), test the h yp

th-

esis that heap sort is an O (n log n) algorithm. Using the co ecien t c y

u

compute, estimate for the heap sort algorithm ho w long it w

uld

tak e to sort a v ector

f

100,000 elemen ts. Is y

ur

v alue in agreemen t with the actual time presen ted is the second table in App endix B? Wh y do y

u

think the v alues computed for small v ectors represen t a b etter predictor

f

p erformance for heap sort than did the equiv alen t analysis p erformed for tree sort?

SLIDE 32 15.5. CHAPTER SUMMAR Y 425 9. Another heap-based sorting algorithm can b e constructed using sk ew heaps. The idea is to simply cop y the v alues from a v ector in to a sk ew heap, then cop y the v alues

ne-b

y-one bac k

ut
f

the heap. W rite the C ++ pro cedure to do this. 10. P erform empirical timings

n

the algorithm y

u

wrote for the previous question. Use as input v ectors

f

v arious sizes con taining random n um b ers. Compare the running time

f

this algorithm to that

f

tree sort and heap sort. 11. Design a sim ulation

f

an airp

rt.

The airp

rt

has t w

run

w a ys. Planes arriv e from the air and request p ermission to land, and indep enden tly planes

n

the ground request p ermission to tak e

.

12. One alternativ e to the use

f

uniform distributions is the idea

f

a w eigh ted discrete probabilit y . Supp

se

w e

bserv

e a real store and note that 65%

f

the time customers will

rder
ne

sco

p,

25%

f

the time they will

rder

t w

sco
ps,

and

nly

10%

f

the time will they

rder

three sco

ps.

This is certainly a far dieren t distribution from the uniform distribution w e used in the sim ulation. In

rder

to sim ulate this b eha vior, w e can add a new metho d to

ur

class random. (a) Add a metho d named weightedDiscret e to the class random. This metho d will tak e, as an argumen t, a v ector

f

unsigned in teger v alues. F

r

example, to generate the distribution ab

v

e the programmer w

uld

pass the metho d a v ector

f

three elemen ts, con taining 65, 25 and 10. (b) The metho d rst sums the v alues in the arra y , resulting in a maxim um v alue. In this case the v alue w

uld

b e 100. A random n um b er b et w een 1 and this maxim um v alue is then generated. (c) The metho d then decides in whic h category the n um b er b elongs. This can b e disco v ered b y lo

ping

through the v alues. In

ur

example, if the n um b er is less than 65, then the metho d should return (remem b er, index v alues start at 0), if less than

r

equal to 90, return 1, and

therwise

return 2. 13. Mo dify the ice cream store sim ulation so it uses the w eigh ted discrete random n um b er generated function implemen ted in the previous question. Select reasonable n um b ers for the w eigh ts. Compare a run

f

the resulting program to a run

f

the program using the uniform distribution.