Outline of Class 43: Trees, Concluded

Miscellaneous

• While most of my coauthors were happy with our chapter, one ripped it to shreds. This may mean that I won't get to grading this weekend, and for that I apologize.
• Don't forget the many forthcoming talks, including today's 2:15 talk on chaos in biology.
• We're not going to do the Huffman coding example in Section 11.7.
• We're not going to talk about priority queues, since what I've been calling "ordered structures" are what Bailey calls "priority queues".
• Note that the implementation in today's outline will not precisely match that of today's class, because I made different design decisions that the class did.

Pause for Reflection

• Let's take a few minutes to reflect on some issues we've seen, directly or indirectly over the first few weeks.
• Early design decisions can have a significant affect on time to implement.
  • If your initial design does not reflect the intended use and complexity of the problem, you may find going more difficult than it should be.
  • For example, we chose to require that the arity of tree nodes be prespecified. This is going to make it significantly more difficult to implement our tree class that permits arities to change.
• Don't just copy other people's code.
  • There are many subtle errors in the sample code that appears in class outlines because I write these outlines "on the fly" as it were.
  • Those who just copy what I write often find that my code works in most but not all cases. Sometimes this is intentional, sometimes it's simply that I haven't tested all (any?) of my code.
  • The solution? Make sure you understand the purpose of the underlying code and that you test the code.
• Thorough testing is needed to catch problems.
  • When testing your programs, you should make sure to test not only a wide variety of cases, but also the "outlier" cases.
  • In your array-based intlists, you should have verified what happened with empty arrays, and with completely filling the array. I know of at least one assignment that had problems at both ends (due in both cases to problems with my own code).
• Early optimization leads to greater complexity.
  • Many of you have tried to make your programs more efficient before you had working programs. Most often, these efficiencies involved complicated but less memory-consuming representations of the underlying information.
  • Complex representations can introduce subtle bugs.
  • It's better to have something that works inefficiently than something that fails efficiently.

Adding a Wrapper to the Implementation

• Let's now consider the implementation of our wrapper-based tree.
• We'll base this implementation on our doubly-linked tree nodes (with both children and parent links).
• What fields do we need?
  • The root of the tree (null if there are no elements in the tree).
  • The current node in the tree.
  • Any others?
• Note that I'm going to stop worrying about memory.
• In Java,

  /** The root of the tree.  Set to null if there are no elements in
      the tree. */
  TreeNode root;
  /** The current element of the tree.  Set to null if it's unclear what
      the current element is. */
  TreeNode current;
  

• We've decided upon two basic constructors: one that builds an empty tree and one that builds a single-element tree.

  /**
   * Create an empty tree.
   * pre: There is sufficient memory.
   * post: The tree is initialized.
   */
  public Tree() {
    root = null;
    current = null;
  } // Tree()
  
  /**
   * Create a tree with one node.
   * pre: There is sufficient memory to create the tree.
   * pre: The value is non-null.
   * post: The tree is initialized.
   * post: The root has zero-arity.
   */
  public Tree(Object rootvalue) {
    root = new TreeNode(rootvalue,0);
    current = root;
  } // Tree(Object)
  

• We can now talk about getting values associated with the current node.

  /**
   * Get the contents of the current postion in the tree.
   * pre: There is a current position.
   * post: The value at that position is returned.
   *
   * @throws TreeException when there is no current node.
   */
  public Object getContents() throws TreeException {
    if (current == null) {
      throw new TreeException("No current node.");
    }
    return current.getContents();
  } // getContents()
  
  /**
   * Get the arity of the current position in the tree.
   * pre: The current position is known.
   * post: The number of direct subtrees is returned.
   */
  public Object getArity() throws TreeException {
    if (current == null) {
      throw new TreeException("No current node.");
    }
    return current.getArity();
  } // getArity()
  

• The setContents() and setArity() methods are similar enough that we won't worry about writing them.
• For setChild() we'll need to do a little bit more work, including
  • verifying arity of current node.
  • creating a new node.
  • setting child and parent references (hopefully, handled by our node class)
• Here's an attempt.

  /**
   * Set one of the children of the current position to a leaf with a
   * particular value.
   * pre: There is a current position.
   * pre: The arity of the current position is sufficient to permit
   *      setting one of its children.
   * pre: Memory is available to create a new node.
   * post: The tree is modified appropriately.
   */
  public void setChild(int childnum, Object value) throws TreeException {
    if (current == null) {
      throw new TreeException("No current position.");
    }
    // We don't need to check arity because the TreeNode
    // setChild does so.
    TreeNode child = new TreeNode(value,0);
    current.setChild(childnum, child);
  } // setChild
  

• What do we do about moving the cursor?
  • Check to ensure that we can move the cursor in the current direction.
  • Move it.
• Here's some corresponding code.

  /**
   * Advance the cursor to a child.
   * pre: There is a current position.
   * pre: The current position has sufficient arity.
   * pre: The current position has the appropriate child.
   * post: The cursor is advanced.
   * post: If any of the preconditions are not met, the cursor
   *       remains on the current node.
   *
   * @throws TreeException if any of the preconditions fail.
   */
  public void down(int childnum) throws TreeException {
    // Get the child, throwing exceptions when necessary
    current = verifiedGetChild(current,childnum);
  } // down()
  
  /**
   * Ensure that a node has a child and return that child.
   * pre: There is a current position.
   * pre: The current position has sufficient arity.
   * pre: The current position has the appropriate child.
   * post: The child is returned.
   *
   * @throws TreeException if any of the preconditions are not met.
   */
  private static void verifiedGetChild(TreeNode node, int childnum)
    throws TreeException
  {
    // Ensure current node.
    if (node == null) {
      throw new TreeException("No current position.");
    }
    // Ensure arity
    if (childnum >= node.getArity()) {
      throw new TreeException("Insufficient arity.");
    }
    // Ensure child
    TreeNode child = node.getChild(childnum);
    if (child == null) {
      throw new TreeException("No such child.");
    }
    // Otherwise we're done
    return child;
  } // verifiedGetChild
  
  /**
   * Move the cursor up the tree.
   * pre: The current position is defined.
   * pre: There is a parent of the current position.
   * post: The current position is changed to the parent.
   * post: If any precondition fails, the cursor stays in the
   *       same place.
   *
   * @throws TreeException if any of the preconditions are not met.
   */
  public void up() {
    // Ensure current node
    if (current == null) {
      throw new TreeException("No current position.");
    }
    // Ensure parent
    TreeNode tmp = current.getParent();
    if (tmp == null) {
      throw new TreeException("No parent.");
    }
    // Do it
    current = tmp;
  } up()
  

• The remainder of the implementation should be similarly easy.