1 / 24

Design Patterns for Self-Balancing Trees

Design Patterns for Self-Balancing Trees. Dung “Zung” Nguyen Stephen Wong Rice University. Motivations. Classic self-balancing tree structures 2-3-4 tree (see next slide) red-black tree (binary tree equivalent of 2-3-4 tree) B-tree (generalized 2-3-4 tree)

stapletonr
Download Presentation

Design Patterns for Self-Balancing Trees

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Design Patterns for Self-Balancing Trees Dung “Zung” Nguyen Stephen Wong Rice University

  2. Motivations • Classic self-balancing tree structures • 2-3-4 tree (see next slide) • red-black tree (binary tree equivalent of 2-3-4 tree) • B-tree (generalized 2-3-4 tree) • Difficult and complex. Where’s the code? • What’s the proper abstraction? • Need to decouple algorithms from data structures.

  3. A A B C A B A 2-3-4 Tree is… • Empty • 0-State: no data element + no sub-trees. • Non-Empty, in 3 possible states: • 1-State: 1 data element + 2 sub-trees. • 2-State: 2 data elements + 3 sub-trees. • 3-State: 3 data elements + 4 sub-trees.

  4. Variant vs. Invariant Operations • Self-balancing insertion is not an intrinsic (invariant) operation of a tree. • What are the invariant operations? • Gettors & Constructors. • Constructive and Destructive operations: • Constructive: Splice a tree into another. • Destructive: Split a tree into a 2-state.

  5. B C A B A A B B C C A C Splittin’ and Splicin’ Splice: Split Up: B Intrinsic operations on the tree STRUCTURE, not the data!

  6. t1.splitUpAt(1) t1.splitDownAt(1) t1 -10 -20 0 10 20 t1.spliceAt(1, t2) -20 0 10 20 -10 t2 -20 -10 0 10 20 α β γ -20 α β γ -10 0 10 20 Structural Operations

  7. t1 t1.splitUpAt(0) t1.splitDownAt(0) 10 10 10 t2 t2.spliceAt(0, t1) Con/De-struction

  8. Host1 Host2 Host3 VisitorA VisitorB Visitor Design Pattern AHost execute(v) AVisitor +case1() +case2() +case3() Invariant: Hosti calls casei of the visitor. Fixed # of methods  fixed # of hosts Non-Extensible!

  9. Host1 Host2 Host3 VisitorA VisitorB Generalized Visitors AHost execute(v) AVisitor +caseAt(int i) Invariant: Hosti calls caseAt(i) of the visitor. Unbounded # of hosts!

  10. TreeN and Algorithms

  11. toString() Algorithm public class ToStringAlgo implements ITreeNAlgo { // Constructors omitted public Object caseAt(int idx, TreeN host, Object key) { switch(idx) { case 0: { return "[ ]"; } default: { String sData= "", sTrees=""; for(int i = 0;i<idx;i++) { sData += host.getDat(i)+" "; sTrees += host.getChild(i).execute(toStringHelp,"| ")+"\n"; } sTrees += host.getChild(idx).execute(toStringHelp," ").toString(); return sData +"\n"+sTrees; } } } ITreeNAlgo toStringHelp = …see next slide…. } Empty Tree Non-Empty Tree “Prefix” data

  12. ToString() Helper private final static ITreeNAlgo toStringHelp = new ITreeNAlgo() { public Object caseAt(int idx, TreeN host, Object prefix) { switch(idx) { case 0: { return "|_[ ]"; } default: { String sData= "", sTrees=""; for(int i = 0;i<idx;i++) { sData += host.getDat(i)+" "; sTrees += prefix + (String) host.getChild(i).execute(this, prefix+"| ")+"\n"; } sTrees += prefix + host.getChild(idx).execute(this, prefix+" " ).toString(); return "|_ "+sData +"\n"+sTrees; } } } }; Empty Tree Non-Empty Tree “Prefix” data

  13. Split-down Collapse/Splice -20 -10 0 10 20 -20 -10 0 10 20 -20 -10 0 5 10 20 Split up Splice 5 5 Vertical Data Transport No net height change except at root and leaves!

  14. Performs a task. invokes No specified semantic! Command1 Command2 Command3 Well-defined, but unrelated semantics. Command Design Pattern Invoker ICommand +Object apply(Object inp) Commands = Lambda Functions Anonymous inner classes provide closures for lambdas!

  15. Insertion Heuristics • Insertion must take place at the leaf. • Tree must grow only at the root. Must transport data from the leaves to the root without affecting the height balance.

  16. Problem: If a child node is too wide, it needs to split up and splice into its parent, but… • The child node does not know where to splice into its parent • The child does not even have a reference to its parent. Solution: Pass a command (lambda) forward from the parent to the child during the recursive call.

  17. Split-up and Splice (Apply) Max width of node class SplitUpAndApply implements ITreeNAlgo { int _order; public SplitUpAndApply(int order) { _order = order;} public Object caseAt(int i, TreeN host, Object param) { if(i <= _order) return host; else { host.splitUpAt(i / 2); return ((ILambda)param).apply(host); } } } Not too wide?  no-op Too wide?  Split up then apply lambda The lambda splices this child into its parent. Lambda/commands enable decoupled communication!

  18. Insertion Algorithm • Find insertion point at the leaf and splice new data in. • Use Split-and-Apply visitor to transport excess data upwards. • Visitor passed as parameter to recursive call. • Non-root: split-and-splice • Root node: split-and-no-op will cause entire tree to grow in height. • Abstract the splice/no-op as a command passed to the visitor! Lambdas simplify code!

  19. 25 Insertion Dynamics 2 elements/node max 25 Too wide! Split up Compare and create splicing lambda λ1 20 10 Splice into parent! Send lambda to child! Too wide! Split up λ2 Compare and create splicing lambda 30 40 5 15 Send lambda to child! Splice into parent!

  20. Find the insertion/splice location public Object caseAt(int s, final TreeN host, final Object key) { switch(s) { case 0: { return host.spliceAt(0, new TreeN((Integer) key)); } default: { host.execute(new ITreeNAlgo() { public Object caseAt(int s_help, final TreeN h, final Object cmd) { switch(s_help) { case 0: { return ((ILambda)cmd).apply(new TreeN((Integer)key)) ;} default: { final int[] x={0}; // hack to get around final for(; x[0] < s_help; x[0]++) { // find insertion location int d = h.getDat(x[0]).intValue(); if (d >= ((Integer)key).intValue()) { if (d == ((Integer)key).intValue()) return h; // no duplicate keys else break; } } h.getChild(x[0]).execute(this, new ILambda() { public Object apply(Object child) { return h.spliceAt(x[0], (TreeN) child); } } ); return h.execute(splitUpAndSplice, cmd); } } } }, new ILambda() { public Object apply(Object child){ return host; }} ); return host; } } } Non-Empty tree?  create a recursive helper Empty tree?  splice into parent Empty tree?  Splice new tree in here! x[0] has the splice location Recur into the child, passing on the splicing lambda Run the given splicing lambda Root has no parent to splice into O(log n) insertion! The beauty of closures!

  21. Deletion Heuristics • Deletion only well-defined at leaf. • Data might exist anywhere in the tree. • Tree can only shorten at root.  Push “candidate” data down from the root to the leaves.  Bubble “excess” data back to the root. Must transport data from the root to the leaves and from the leaves to the root without affecting the height balance.

  22. Deletion Algorithm • Identify candidate data • split down at candidate and collapse with children. • If root is a 2-node, then tree will shorten. • Data to delete will appear as 2-node below leaves. • Use Split-and-Apply to transport excess data upwards. No Rotations!

  23. Deletion Dynamics 2 elements/node max Remove “30” Split-down candidate element and collapse with children 20 Split-up and splice as needed 10 30 40 5 15 25 35 45 Delete it!

  24. Conclusions • Proper abstraction leads to • Decoupling • Simplicity • Flexibility & extensibility • Generalized Visitors open up new possibilities. • Self-balancing trees teach • Abstract decomposition • Design patterns • Component-frameworks • Lambda calculus • Proof-of-correctness & complexity analysis

More Related