This shows you the differences between two versions of the page.

Both sides previous revision Previous revision Next revision | Previous revision | ||

cs-236:optimizing-rule-evaluation [2017/12/22 21:17] kylej13 [Rule Grouping and Evaluation Order] |
cs-236:optimizing-rule-evaluation [2017/12/22 21:21] (current) kylej13 [Rule Grouping and Evaluation Order] |
||
---|---|---|---|

Line 66: | Line 66: | ||

Reversing the edges in step 1 is very direct. Returning to the example from the previous section, the reversed graph as an adjacency list is | Reversing the edges in step 1 is very direct. Returning to the example from the previous section, the reversed graph as an adjacency list is | ||

<code> | <code> | ||

- | Reverse Dependency List | + | Reverse Dependency Graph |

R0: R1 | R0: R1 | ||

R1: R0,R2 | R1: R0,R2 | ||

Line 84: | Line 84: | ||

</code> | </code> | ||

- | The last step to compute SCCs starts a depth-first search from the greatest post-order traversal number (POTN) to the least POTN on the ''original graph.'' In the view of a stack, that is the top of the stack to the bottom of the stack. Any vertex visited in the search belongs to the same SCC. The process is repeated until everything is visited in the graph. For the running example, the first depth-first search is started from vertex ''R3'' to create the SCC of ''{R3}''. The ''R3'' vertex is removed from the stack. ''R4'' is now the top, the depth-first search creates the SCC ''{R4}'', and it is then removed from the stack as well. ''R0'' is now the top of the stack, so a depth-first search is started at ''R0''. '''The depth-first search must not reset the visited information between searches.''' The visited information is what prevents the search from moving into another already completed SCC. The second depth-first search from ''R0'' yields the SCC ''{R0, R1, R2}''. The vertex is popped from the stack leaving ''R1'' on top. ''R1'' has already been visited so it is popped. The same is true for ''R2''. If you printed out the strongly connected components in the order you discovered them it would look like: | + | The last step to compute SCCs starts a depth-first search from the greatest post-order traversal number (POTN) to the least POTN on the ''original graph''. In the view of a stack, that is the top of the stack to the bottom of the stack. The process is repeated until everything is visited in the graph. This produces a DFS forest where each tree represents one SCC. For the running example, the first depth-first search is started from vertex ''R3'' to create the SCC of ''{R3}''. The ''R3'' vertex is removed from the stack. ''R4'' is now the top, the depth-first search creates the SCC ''{R4}'', and it is then removed from the stack as well. ''R0'' is now the top of the stack, so a depth-first search is started at ''R0''. '''The depth-first search must not reset the visited information between searches.''' The visited information is what prevents the search from moving into another already completed SCC. The second depth-first search from ''R0'' yields the SCC ''{R0, R1, R2}''. The vertex is popped from the stack leaving ''R1'' on top. ''R1'' has already been visited so it is popped. The same is true for ''R2''. If you printed out the strongly connected components in the order you discovered them it would look like: |

<code> | <code> | ||

Strongly Connected Components: | Strongly Connected Components: |