Administration

• CI meetings resume next week, as usual• Some TAs in labs, plus Dr. Betz

– Go to your lab as usual– If your TA is not there, ask for help from

another TA– Update your wiki as usual we are still

grading its quality / your project management• Your TA will grade if he/she still working• Or if your TA is out at end of term, Dr. Betz + CI will

assign grade, based on wiki quality & CI input

• Self-evaluation of oral presentation 1– Due Monday, March 9

BFS with Re-expansionbool bfsPath (Node* sourceNode, int destID) { ... bool found = false;

while (wavefront not empty && has entry < bestPathLen) { waveElem wave = wavefront.front (); wavefront.pop_front(); // Remove from wavefront Node *node = wave.node;

if (wave.pathLen < node->pathLen) { node->reachingEdge = wave.edgeID; node->pathLen = wave.pathLen;

if (node->id == destID) { found = true; bestPathLen = node->pathLen; }

BFS with Re-expansion

for each (outEdge of node) { Node *toNode = outEdge.toNode; wavefront.push_back ( waveElem(toNode, outEdge.id, node.pathLen + travelTime (outEdge)); } } // End if best path to this node } // End while wavefront might yield a better solution

return (found); }

Complexitywhile (wavefront not empty && has entry < bestPathLen) {

• If we use a visited flag:– Executes maximum N times– Work in loop is O(1)O(N)

~100,000 10-7

< 1 s

• BFS with re-expansion:– Difficult to bound – But in practice much less than O(2N) of DFS with re-expansion

• How could we limit re-expansion?

Limiting Re-expansion

• Only re-visit a node in BFS when– We find a new path with a lower cost to that

node

Re-Expansion Wastes CPU

BFS Wavefrontbool bfsPath (Node* sourceNode, int destID) {

list<waveElem> wavefront;

while (wavefront not empty && has entry < bestPathLen) { waveElem wave = wavefront.front (); wavefront.pop_front(); // Remove from wavefront Node *node = wave.node;

if (wave.pathLen < node->pathLen) { ... wavefront.push_back ( waveElem(toNode, outEdge.id, node.pathLen + travelTime (outEdge)); ...

78, 20s 2, 5s 39, 12s Wavefront: FIFO Queue

c, 10 s

Take the Smallest Entry in Wavefront?source

dest

c

a

b

d

wavefront =0

1

2

3

{0/0s}{1/20s,2/5s}{1/20s,1/10s}{1/20s,3/16s}

4

{1/20s,4/19s}{1/20s}

b, 5 s

d, 16 s

e, 19 s

e

t = 5 s

t = 5 s

t = 20 s

t = 6 s

t = 3 s Found shortest path with no re-expansion

Djikstra’s algorithm

How Much Work To Get Smallest?

• Linked list– Insertion: O(1)– Remove smallest: scan entire list

• O(M), where M is active wavefront entries• M can be up to O(N), but usually more like O(N0.5)

• Binary tree?– Insertion: O(log M)– Remove smallest

• O(log M)

78, 20s 2, 5s 39, 12s list<waveElem> wavefront

Overall Complexity

• O(N) items added/removed in wavefront– Work to remove next item:

• Linked list: O(M) O(N0.5) to O(N)• Binary tree: O(log M) O (log N)

• Overall complexity– Linked list: O(N1.5) to O(N2)

• N 100,000 and ~10-7 s per function• 3.2 s to 1000 s (wide range!)

– Binary tree: O(N logN)• <1 s

Anything Faster than Binary Tree?

• Heap– Insertion: O(log N)– Removal of smallest element: O(log N)– But absolute time smaller than binary tree

(Min) Heap

• Like a binary tree– But not fully sorted

• Key of parent < key of children– For all nodes in the tree– Very good for priority queues

3

20 36

40 35 37 60

50

Smallest item always at root

of heap

No ordering between sibling

nodes in the heap

BFS and Dijkstra Demo

Better than Dijkstra’s Algorithm?

Dijkstra / BFS: Not So Smart!

Why are we examining nodes in the wrong direction?Wasted CPU time!

Ideas?

• Only look at nodes that take us closer to the destination?– distToDest(node) < distToDest (predecessor)

• Too severe – can result in no path, or not shortest path

A* Algorithms

• Enhancements to Dijkstra’s algorithm• Use domain-specific heuristics

– E.g. we are working in a map– Can estimate which graph nodes are closer vs. further

from dest

• Incorporate into the wavefront sorting/ordering• Look at the most promising partial solutions first• “Best-first search”

A* Search

Mostly searches in the right direction, but will explore some in other directions

Can go around blockages (e.g. 401)

A* Demo

Milestone 3 Speed

• 11% of final mark• 7%: path quality and speed

– Some cleverness required for full marks– Implement some A* techniques to pass hardest speed

tests– Read up online

• Milestone 4 (another 11% of mark)– Find a good path to connect M intersections

• Courier company

– Will have a CPU time limit– Will benefit from fast path-finding algorithms

• A good milestone 3 implementation will help you!

Milestone 3 User Interface

• Make it usable: 4% of final mark• Lots of ideas in m3 handout

– Don’t need to implement them all