(les05)-linkedlistshashtables(1)

7/25/2019 (les05)-linkedlistshashtables(1)

1/50

Algoritmen & Datastructuren2014 2015

Stacks, Queues & Hash Tables

Philip Dutr

Dept. of Computer Science, K.U.Leuven


2/50

Lecture Overview

Copyright Ph.Dutr, Spring 20152

Stacks and Queues Stacks

Array implementation

Resizing

Array vs Linked List

Queues

Hash Tables

Hash function

Collisions Separate Chaining

Linear probing

Applications


3/50

Stacks and Queues


S&Q = Fundamental data types. Sets of objects

Operations: insert, remove, test if empty.

Which item do we remove?

Stack Remove the item most recently added.

Analogy: Cafeteria trays, Web surfing.

Queue Remove the item least recently added.

Analogy: Waiting line.


4/50

Stacks and Queues



5/50

Stacks


E.g. Stack of String objects


6/50

Stacks



7/50



8/50



9/50



10/50



11/50

Array implementation of a stack


Use array s[ ] to store N items on stack.push() : add new item at s[N]

pop() : remove item from s[N-1]


12/50



13/50

Resizing


When array is full Make new bigger array

Copy all elements (this is the cost!)

New size must not be too big (memory),

but also not too small (too often) Good practice: size x 2

Why twice the size? Cost of inserting the first N elements:

N + (2 + 4 + 8 + + N) = ~ 3N


14/50

Array vs. Linked List


Linked-list implementation. Every operation takes constant time in the worst case.

Uses extra time and space to deal with the links.

Dynamic-array implementation.

Every operation takes constant amortized time. Less wasted space.


15/50

Queues linked list



16/50



17/50

Queues -- arrays


Use array q[] to store items in queue.

enqueue() : add new item at q[tail]

dequeue() : remove item from q[head]

Update head and tail modulo the capacity.

Dynamic resizing (cfr. Stacks)


18/50

Hash Tables


We want to store & search key-value pairs


19/50

Hash Tables


Ordinary arrays Store value with key k in position a [k]

Hash table

More possible key values thanpositions available

Mapping of key values

positions in table

How to compute the hash-function?

Collisions are a problem


20/50

Hash function


Transform a key to an integer [0, M-1] M = size of array

Requirements:

Easy to compute Uniform distribution of keys

Same keys must produce same hash value

Example: phone numbers Bad: hash = first 3 numbers

Better: hash = last 3 numbers


21/50

Hash function, modular hashing


M = prime number keys = positive integers

hash value = key%M

Even distribution of keysbetween 0 and M-1

What if M is not prime? Keys = base 10

M = 10k


22/50

Hash function, compound keys


Key = multiple integer fields: first, sec, third

E.g. 345-485-123

Consider this as a key of 3 digits in base R (R > M) E.g. above: base 1000

hash = (((first*R+sec)%M)*R+third)%M


23/50

Uniform hashing assumption


Given a typical set of keys ... Does the hash function produce uniform hash values?

E.g. throwing balls in bins

E.g. words in Tale of Two cities (10679 keys, M=97)


24/50

Collisions


Two keys hash to the same index Unless Mis very very, very, verylarge,

collisions will happen

How to deal with collisions efficiently? Separate chaining

Linear probing


25/50

Separate Chaining


Use an array of linked lists Hash: map key to integer i between 0 and M - 1

Insert: put at front of ithchain (if not already there)

Search: only need to search ithchain


26/50

Separate Chaining


Expectation: each list has

= N/Melements Proposition:

#keys in list is (within a small constant factor) very close

to N/M

Proof probability of having k keys map to the same value:


27/50

Separate Chaining


Consequences Number of probes for search/insert is ~ N/M

M too large too many empty chains

M too small

chains too long

Typical choice: M ~ N / 5 constant-time ops


28/50

Linear probing


Store N key-value pairs in a table of size M, M >N

Use empty slots to resolve collisions

If slot is taken, use next available slot

Search for an element:

First, compute hash

if key == search key: element found!

hash resolves to empty position: element is not in table

if key != search key: try next slot in table


29/50



30/50



31/50

Linear probing & Clustering


Cost depends on clusters of elements in table

Long clusters tend to become longer (more chance of

adding to an already existing cluster)


32/50

Analysis of linear probing



33/50

Chaining vs. Probing


Separate chaining

Easier to implement delete

Performance degrades gracefully

Clustering is less sensitive to badly-designed hash

function.

Linear probing

How to delete elements?

Less wasted space Clustering can be a problem


34/50

Unexpected application ...


How to manage/plan/regulate a citys parking spots?

# parking spots in a street

Car arrives and picks random spot

E.g. in front of home or shop

If spot is taken, try next spot etc.

How much traffic will be on the streets looking for a

parking spot?


35/50

Applications: Exception filters


Read in a list of words

Detect out all words that are { in, not in } the list


36/50

Application: ray tracing



37/50

Application: Ray Tracing


environment


38/50

Application: Ray Tracing



39/50

Grid Data Structures

Grid and linearized grid

2

1

0

0 1 2

0 1 2 3 4 5 6 7 8

2D

1D

0

1

2

Copyright Ph.Dutr, Spring 2015 39


40/50


Data structure using linked lists0 1 2 3 4 5 6 7 8

1 1 0 2

1

0

2 0 2 2

1



41/50


Data structure using dynamic arrays0 1 2 3 4 5 6 7 8

1 1 0 0

1

2

1

2

0 2 2

2 0 2 1 2 1 2 1 4 3 2 2 2 1 2 1 2 1

: unused space



42/50

Hashed Grid

Row displacement compression

1

5

11

12 15

C



43/50

Hashed Grid


1

5

11

12 15

C O

H



44/50

Hashed Grid


1

5

11

12 15

1

1

C O

H

0



45/50

Hashed Grid


1

5

11

12 15

1

5

1 5

C O

H

0

1



46/50

Hashed Grid


1

5

11

12 15

1

5

11

111 5

C O

H

0

1

1



47/50

Hashed Grid


1

5

11

12 15

1

5

11

12 15

12 11 151 5

C O

H

0

1

1

3



48/50

Hashed Grid


12 11 151 5

O

HC[i,j] H[O[i] + j]

0

1

1

3



49/50

Hashed Grid


12 11 151 5

D O

H|D| + |O| + |H|


50/50

Applications

Ray tracing large models

St.Matthew

Scene: 372.77 Mtriangles, 12.50 GB

Time to image: - / 60.75 s

Memory usage: - / 2.36 GB

Dav

id Scene: 56.23 Mtriangles, 1.89 GB

Time to image: 7.55 s / 10.21 s

Memory usage: 1.17 GB / 379.94 MB

Copyright Ph Dutr Spring 2015 50

(les05)-linkedlistshashtables(1)

Documents