Class summary: Circular References and Intro to Hashtables

Copyright (c) 2017 Kathi Fisler

1 Circular References

One of the interesting things about our Book and Patron definitions is that they refer to each other: A patron refers to books, which refer to their borrowers, which refer to their books, and so on. Let’s look at these circular dependencies in data a bit more closely.

Here are versions of the Account and Customer classes that set up a circular reference: each Account refers to its owners, and each Customer refers to their account. To keep the example simple, we will assume that each Customer can have only one account.

Let’s now create a new customer and a new account for them:

How do we fill in the blank in the Customer? We’d like to say new_acct but Python (and most other languages) will raise an error that new_acct isn’t defined. Why is that?

When given this assignment, Python first evaluates the right side, to get the value or memory location that should be stored in the dictionary for new_acct. If we filled in the blank with new_acct, Python would start by running:

To do this, it needs to look up new_acct in the dictionary, but that name isn’t in the dictionary yet (it only goes in after we compute the value to store for that name). Hence the error.

1.1 Use assignment to create circular data

To get around this, we leverage the ability to update the contents of memory locations after names for data are in place. We’ll create the account partially, but without filling in the Customer. Then we create the customer to reference the new Account. Then we update the account owners with the now-created customer:

Note here that each part gets a spot in memory and an entry in the dictionary, but the data hasn’t been finished yet. Once we have the data set up in memory though, we can update the owners component to the correct value.

Here’s what this looks like at the level of memory and the dictionary after running the first two lines:

Then, when we run the third line, we create a new list containing new_cust and update the owner list within new_acct:

Notice that the two owners lists each live in memory but aren’t associated with names in the dictionary. They are only reachable going through new_acct, and after the update, the empty list isn’t reachable at all.

If we had instead done the owner update using append, as in:

We would have updated the list at location 1015 instead of create a new location for a new list, as follows:

Either approach (append or a new list) works fine. The only difference is whether a new list gets created, as shown in these two memory examples.

1.2 Testing Circular Data

When you want to write a test involving circular data, you can’t write out the circluar data manually. For example, imagine that we wanted to write out new_acct from the previous examples:

Because of the circularity, you can’t finish writing down the data. You have two options: write tests in terms of the names of data, or write tests on the components of the data.

Here’s an example that illustrates both. After setting up the account, we might want to check that the owner of the new account is the new customer:

Here, rather than write out the Customer by hand, we drop in the name of the existing item in memory. This doesn’t require you to write ellipses. We also focused on just the owner component, as a part of the Account value that we expected to change.

1.3 Bonus: A Function to Create Accounts for New Customers

What if we turned the sequence for creating dependencies between customers and their accounts into a function? We might get something like the following:

This looks useful, but it does have a flaw – we could accidentally create two accounts with the same id number. It would be better for us to maintain a variable containing the next account id to use, to guarantee that the same id gets used only once. How might we augment the code to do this?

Here, we create the next_id variable to hold the next id number to use. When we create an Account, we update next_id to the next unused number. Problem solved!

Well, almost. Now we’re at something that is specific to Python.

When we were still working in Pyret, we talked about what happens to the dictionary when we call a function: we make a separate area of the dictionary for that function, and we put the values of the parameters in that area of the dictionary. When the function ends, its piece of dictionary goes away.

In our code above, we have a variable next_id set up outside the create_acct function. Inside the function, we are assigning to a variable next_id. Is this the same variable from outside the function though, or are we trying to create a new variable (as we do for new_acct or new_cust). Python can’t tell which one we want.

To tell Python that we are trying to use the copy of the variable that is outside the function, we have to add a line telling it that. We do that by using a global annotation inside the function. Here’s the final code:

This isn’t something you’ll be tested on – it is just here to show you how to do this in case you are interested.

2 Introduction to Hashtables

2.1 Finding Items in Memory

When someone asks for an account balance, they usually provide their account number. This suggests that we need a function that takes an account number and returns the account value with that id. From there, we can dig into the account to get the balance.

This means we need some data structure to store all of the accounts. We’ve seen lists and tables for this purpose. Let’s use a (Python) list. Such a list might look as follows:

For now, we’ll ignore the owners component – it isn’t relevant to our discussion and omitting it will make examples easier to write out.

So we need to search a list for the account with a given id. We’ve written such search code many times at this point. Here it is again for reference, with a Python test function for good measure:

As we discussed earlier in the course, this function takes linear time in the number of accounts in the worst case. For a real bank, that’s a significant number. How can we do better?

Now that we’ve been thinking about memory a bit, we can reframe the question about finding an account. Finding an account is ultimately about finding the account in memory. Once we know the memory location of the account we’re trying to find, we can operate on that account however we want.

In the find_acct version, we use the dictionary to find the list in memory, then iterate through all the accounts in the list, checking their ids until we find the one that we want. But what if we had a way to predict where the account we want would be, so we could go directly to that memory location? Could we have to set up the data to enable that?

Looking at our memory diagrams, we see that the items in the list are in order in memory. So if we know which position we want within the list, we should be able to hop to that spot immediately once we know the memory location of the list itself (basically, we take the address of the list itself and add the list position to get to the right memory spot). Things are a touch more complicated than this in practice (because we’ve simplified the structure of lists in memory the last several lectures), but this is the intuition.

There’s nothing in the programming language that lets us grab memory locations from the dictionary and add offsets to them for specific elements. But there are data structures that effectively do that for you. Enter the hashtable.

2.2 The Hashtable Datatype

For today, we’re just going to show you a hashtable and how to use it. Next class, we’ll discuss how it works.

Hashtables are data structures that let us map quickly from some notion of keys (like account numbers or course codes) to values. When we set up a hashtable, we write a series of entries of the form

Here’s what a hashtable mapping id numbers to accounts might look like:

We create a hashtable by using curly braces instead of square brackets (as we do for creating lists) on the outside, and by using the key: value form for each item. The hashtable above has five account IDs that map to accounts with those same ID numbers.

Now, if we want to get the account with ID 1 from the hashmap, we can simply write:

This says "in the accts_HM hashtable, get the value associated with key 1. Because of the way hashtables are set up within Python (and any other language), Python can hop to the memory address in constant time and extract the Account with ID 1.

There are many more things to discuss about hashtables: how to use keys that aren’t numbers, how they work, and when to use them. All of these are coming up in the next couple of lectures.