Class 41: Dictionaries

Held Monday, April 19

Summary

• The dictionary ADT.
• Implementations of dictionaries
  • Lists
  • Search trees
  • Hash tables
• Uses of dictionaries
• Reading: Java Plus Data Structures, chapter 9.

Contents

Notes

• Today at noon, Clif Flynt will be talking about UML. UML is a useful tool for thinking about object-oriented design, and you may find it helpful in thinking about your projects.
• Don't forget that the descriptions of your project components are due tomorrow at the start of class.
  • We'll discuss them in class on Wednesday. Our goal will be to identify and ``hash out'' differences.
• Friday will be the last day (I think) that prospective students visit.
• Mr. Walker will be visiting class this week or next.
• I've checked, and Mr. Stone will be using Java in CS223 next year.

Dictionaries

Some of this information was covered in our lab on vectors.

• In our investigation of vectors and arrays, we've seen structures that collect objects in which the objects can be indexed by numbers.
• Are there other ways to index collections? Yes, we could index collections by objects (strings, BigNums, whatever).
• Collections of objects indexed by objects are called dictionaries. Some people also refer to them as keyed tables.
• Some more terminology:
  • The objects we're using as indices are called keys.
  • The objects we're looking up are called values.
• Why do we do we want dictionaries? They make many tasks more convenient.
  • Keeping track of objects we've seen. If an object is an index in the dictionary, we've seen it; if it's not an index in the dictionary, we haven't seen it. This would be helpful for our puzzle solver from the previous class.
  • Counting things We can use the dictionary to associate a counter with each object; when you see another copy, increment the counter.
  • Databases. There are a number of techniques for implementing and thinking about databases. Dictionaries provide a simple mechanism for single-keyed databases.
• How do we do build dictionaries? There are a number of techniques, including linked lists of key/value pairs. and won't worry about how they work. Later, we'll look at how to build them.
• What features do we need in a dictionary? Some are similar to those we need for vectors.
  • Add something to the dictionary (requires a key and value).
  • Look up something in the dictionary (requires a key, returns a value).
  • Remove something from the dictionary.
• Others correspond more to the different structure of dictionaries.
  • List/iterate all the keys in the dictionary.
  • List/iterate all the values in the dictionary.

Dictionaries vs. Databases

• Note that dictionaries are not the same as databases.
• Why not? There are a number of reasons.
• Dictionaries have a single key, and that key provides the only way to access information.
  • Databases may have multiple keys. You may also access information using other fields. For example, while a database may be keyed by ID#, you might still be able to search by name.
• A dictionary returns a single object given a request.
  • A database may return multiple objects (e.g., all the students with a B).

A Simple Implementation

• How can we implement dictionaries? There are a number of techniques.
• We could define a Pair object that joins a key and value.
• We could make an unordered array, vector, or list of those objects.
  • To insert an element, we put it at the beginning or end of the array, vector or list. This is generally O(1), depending on the structure we use.
  • To look up an element, we step through the pairs one by one, comparing the key we are searching for to the key in each pair. This is O(n), where n is the number of elements.
• We could make a sorted array of those objects (a sorted array being one that is always sorted).
  • To insert an element, we put it at the appropriate place, shifting as necessary. This is O(n) and is again limited by the size of the array.
  • To look up an element, we do binary search on the sorted array.
• It turns out that by using more sophisticated structures (e.g., nonlinear structures) or techniques (e.g., manipulating keys), we can do better.

Search Trees

• Another strategy for building dictionaries is to use search trees. Search trees use the basic idea of binary search, but encapsulate it in a particular way.
• We can think about the structure by revisiting binary search.
• We've used binary search on arrays, but are there other structures we can use it on? We might answer this by considering operations.
• What operations do we need to do binary search?
  • Grab the ``middle'' element.
  • Grab everything less than the ``middle'' element.
  • Grab everything greater than the ``middle'' element.
• We might build a data structure (or at least an interface) that directly supports those three operations.

  public interface BinarySearchable 
    extends Collection
  {
    /** 
     * Get the ``middle'' element in the collection. 
     * Pre: The collection is nonempty.
     * Post: Returns some designated element in the collection.
     */
    public Object middle();
  
    /** 
     * Get elements in the collection that are smaller than the
     * middle element.
     * Pre: The collection is nonempty.
     * Pre: The collection has not been modified since the last call
     *   to middle.
     * Post: Returns the smaller elements.
     */
    public BinarySearchable smaller();
  
    /** 
     * Get elements in the collection that are larger than the
     * middle element.
     * Pre: The collection is nonempty.
     * Pre: The collection has not been modified since the last call
     *   to middle.
     * Post: Returns the larger elements.
     */
    public BinarySearchable larger();
  
    /**
     * Determine if the collection is empty.
     */
    public boolean empty();
  } // BinarySearchable
  

• We already know how to implement such structures using sorted arrays. An advantage of sorted arrays is that all the operations are O(1) (as long as we're cautious about how we represent these structures).
• Can we also represent such structures as linked objects, using nodes?
• Yes, we'll give each node two links: one to smaller things and one to larger things.

  public class BinarySearchNode 
  {
    /** The contents of this node. */
    Object contents;
    /** A linked structure of things smaller than this node. */
    BinarySearchNode smaller;
    /** A linked structure of things larger than this node. */
    BinarySearchNode larger;
  } // class BinarySearchNode
  

• For example, we might build the following structure for the first six letters of the alphabet.

        D
      /   \
     B     F
    / \   / \
   A   C E   G
  

• Similarly, here's a structure for the names of some faculty members.

            Rebelsky
           /        \
       Ferguson    Walker
      /     \       /    \
  Adelberg Herman Stone Wolf
           /   \
        Flynt  Jepsen
  

• Such structures are called binary search trees
  • Binary: there are two links.
  • Search: you use them for looking for things.
  • Trees: They look somewhat like upside-down trees .
• How do we use search trees? The same way we use binary search. To find an element in a search tree, you compare the object you're looking for to the current node. If the object you're looking for is smaller, you follow the left branch. If the object you're looking for is bigger, choose the right branch.
• We can use a similar process to insert an element.
• If we can make the tree relatively balanced, this gives an O(log₂ n) algorithm. Unfortunately, keeping the tree balanced is difficult. That is a topic for CSC301.
• In order to implement BinarySearchable, we'll build a wrapper class. This class will permit us to
  • Represent empty collections.
  • Keep track of the Comparator used to determine large and small.
• That is,

  public class SearchTree
    implements BinarySearchable
  {
    /** The contents of the tree. Set to null for empty trees. */
    BinarySearchNode tree;
    /** The comparator used to determine large/small. */
    Comparator compare;
    ...
  } // class SearchTree
  

History

• Created Monday, January 11, 1999.
• Added short summary on Friday, January 22, 1999.
• Filled in the details on Monday, April 19, 1999. Details were based, in part, on outline 16 and outline 46 of CS152 98S.
• On Monday, April 26, 1999, removed uncovered section on nonlinear structures.