Held Wednesday, November 10, 1999
Overview
Today we will consider a high-level data structure, the dictionary.
Dictionaries associate values with ``keys''. In some sense, dictionaries
are like the options class from our project.
Notes
- It seems that assignment 4
revealed some interesting design issues. We'll chat about some today
and some on Friday.
- There was a bug in the tester class. Since that class was late and
it had a bug, I'll give 5 points extra credit to those who turn in
the assignment by 5 p.m. today and no penalty for those who turn it
in by Friday.
- For Monday, I'd like mostly-working implementations of your components
of the project.
- I'd prefer that you also start working on integration. However, it's
also okay if you wait until everyone turns in their partially-working stuff.
- We should consider timelines for the project. My intent was that we discussed
stuff on Wednesday, November 17, did
"integration testing" on November 19, worked over the weekend on
polishing presentations, went over our presentations on Monday,
November 22, and then gave an open presentation lunchtime on the 22nd
(I'll spring for pizza).
Contents
Summary
- Due: Assignment 4
- Some notes on lists
- The dictionary ADT
- Applications of dictionaries
- 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, Integers, 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
an earlier 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.
- Note that the ``Options'' class for our mail system is a kind of
dictionary: given the name of an option, it can return the value of
that option.
- That group may want to lead us in a discussion of some general design
issues.
- Can clients create new options? Why or why not?
- How do we handle different types of options (ints vs. strings vs. ...).
- ...
- 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.
- 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).
Tuesday, 10 August 1999
- Created as a blank outline.
Wednesday, 10 November 1999
Back to Stack Lab.
On to Search Trees.