---
title: Homework 6
tags: Homeworks-F25
---

# Homework 6: As Memory Serves

### Due: Monday, November 24th at 11:59 pm

### Setup
- Fork [this](https://edstem.org/us/courses/84795/workspaces/p8l2LcWiEavoijh68eiPbrMrT1kUqb65) Ed Workspace (or find it in the public workspaces tab)
- Create a document (in your favorite editing app) named `tracing` in which you will answer Tasks A-1 through A-6 (export as a PDF before handing in)
- Do **not** put your name anywhere in your homework files

### Resources
- [Python guide for Ed Workspaces](https://hackmd.io/@cs111/python-guide-ed#Writing-and-running-tests)
- [Python testing and style guide](https://hackmd.io/@cs111/python-style-guide-2025)
- [TA hours](https://brown-csci0111.github.io/pages/calendar)
- [EdStem](https://edstem.org/us/courses/84795/)

## The Assignment
Piper the Pipping Pilot is going shopping with her family to decorate the flightdeck on her airplane! When shopping, she has to keep track of all her family members' orders and the items that they are ordering. In this homework, you will keep track of these orders through memory diagrams.


## Learning Objectives

This assignment mostly has you working with memory diagrams, which we cover to help you understand what your code actually does when updating data. The last part gives you some practice with dictionaries, which you will need for the final project.

:::info
Learning Goals:
- Check your understanding of how different bits of code affect the connections between data at the level of memory
- Make sure you can write tests for functions that update data in memory
- Practice using dictionaries
:::

## Memory Tracing (No Programming)
**For tasks involving memory diagrams (Task A-2 and Task A-5), use [this template](https://docs.google.com/spreadsheets/d/1UCDjnh2U_KU1cRH7Q2LD0AQUMZAEk2rtSWPQSYcYyYI/edit?usp=sharing) as a starting point.** To edit it, make a copy (File -> Make a copy). This is the same template that you saw in Lab 10 – refer to that lab for an example of how to fill out a memory diagram.

To turn in your final memory diagrams, take a screenshot of each diagram and insert it into a single file called `tracing.pdf`. Clearly mark which image goes with which memory point. Your final submission for this section should contain your memory diagrams alongside your written answers (see the note at the bottom of this section for full hand-in instructions). *Do not submit the spreadsheet itself -- we want this all in one document to make it easier to grade, and there will be a grade deduction if the grader can't easily find the information for each task.*

__The Moon Collection__ is part of a program for managing orders in an online store. There is a data structure for the `Items` for sale, as well as a catalog of all items. There is a data structure for `Orders`, which capture the name of a customer and a list of items that the customer wants to buy. There are also two versions of a function to update the price of an item in the catalog. All of this is managed in `hw6_code.py`, provided to you in the Ed Workspace. **Do not run this code yet.**

**Task A-1:** *Without running the program* or drawing a memory diagram, predict what will be in each of `k_order`, `m_order`, and `catalog` (items and their prices) after the four expressions evaluate. Write down your answers.

*Note: You will not lose points for an inaccurate prediction. The point of the question is to help you calibrate your understanding of memory as you work through the problem.*

*Note: In the code, there is a line that says `global catalog`. This just means that the function is going to update the value of `catalog` which was defined outside the function.*

**Task A-2:** There are four comments in the code marked "Memory point." Show the contents of memory (variables and heap) at each of these four points. **Make sure to include a different memory diagram for each memory point (you should have 4 distinct diagrams).** Remember to use [the template](https://docs.google.com/spreadsheets/d/1UCDjnh2U_KU1cRH7Q2LD0AQUMZAEk2rtSWPQSYcYyYI/edit?usp=sharing) for your memory diagrams.

**Task A-3:** *Based on your memory diagram*, predict what will be in each of `k_order`, `m_order`, and `catalog` (items and their prices) after the four expressions evaluate. Write down your answers.

*Note: You will not lose points for an inaccurate answer for this task (as long as you appeared to take the problem seriously)*

**Task A-4:** Now, copy and run the code and compare the final contents of `k_order`, `m_order`, and `catalog` to your answer to the previous task. If they differ, that is an indication that you have a mistake in your memory diagram.

:::spoiler Hint for checking your work
**We will showed an example of this in class in the second memory lecture.** Add a `pass` statement at the end of this code, and add a breakpoint (click to the left of the `pass` statement's line number, so that a red dot appears).

Run the debugger (Run -> Debug) and observe what the contents of `k_order`, `m_order`, and `catalog` are on the left side of the screen.
:::

**Task A-5:** Revise your memory diagrams from **Task A-2** as needed and write down your final answers for each of the four memory points.

:::spoiler Hint for checking your work as you go
You can add breakpoints in other parts of your code and step through to check if the values each variable takes on are the same as you put in the memory diagram at each step. Refer back to Lab 9 and the secone memory lecture for instructions on using the debugger.
:::

**Task A-6:** Reflect on your process: were your predictions correct? If yes, write down one way you approached the tasks that you feel was particularly helpful in your thinking. If no, write down a *conceptual misconception* (not just a wrong answer, but where you think you had a mistake in your thinking) you had and fixed.

:::warning
**Note:** Your final file should include:
1. Your prediction from task A-1
2. Your initial answer from task A-3
3. Images of your final, revised memory diagrams from task A-5 (builds upon / corrects any mistakes from the memory diagrams from task A-2). Clearly mark which image goes with which memory point.
4. Your reflection from task A-6

Remember to check the [Handin](#Handin) section for more details!
:::

## Testing Under Mutation

For this section, work in `test_hw6.py`. We will ask you to create test data and write assertions for functions that we will describe but not provide, meaning that you will **not be running your testing file.** The point of this section is to show that you understand how you would set up data for testing under mutation!

Say you were given a function `discount_order(ord : Order) -> None` that goes through every `Item` in the provided order and takes $1 off the price of each item that costs more than $10.

**Task B-1:** Write a function called `test_discount_order` that sets up at least two `Order`s (similar to how `k_order` and `m_order` were set up above, but you should make your own) and tests that `discount_order` behaves as intended. **You are only writing a test function for this question**. You are NOT writing code for `discount_order` itself.

You will be graded on what your `Order`s look like (think back to the things you learned about writing comprehensive test examples in Pyret -- what sorts of `Orders` would be helpful for testing that `discount_order` works?). You will also be graded on the correctness of the assertions you write and whether they correctly test the effects of the `discount_order` function as described.

Recall that, when testing under mutation, we follow a template where we set up data, call the mutating function, and then test the side-effects of the mutation.

:::spoiler Template for testing under mutation
:::info
Your function will need to set up some data (items and orders), make one or more calls to `discount_order`, then run a series of assertions to check the impacts of the `discount_order` call on the data. The general form of your function should be as follows:

def test_discount_order():
    "SETUP"
    # create Orders here

    "PERFORM MODIFICATIONS"
    # call discount_order on the Orders

    "CHECK EFFECTS"
    # assertions go here

:::

---

Now let's assume that someone wants to use a `dict` from strings to floats, instead of a list of `Item`s, to keep track of the catalog. For example, the catalog in part A, rewritten in this format, would look like

catalog = {"Basics of Flight": 17.95, "Radio": 10, "Laptop": 900}

You're given a function `update_cat_dict(cat_dict : dict, itm : Item)` that adds a key-value pair of `itm`'s description and price to the given dictionary if and only if a key of the given description doesn't already exist in `cat_dict` (for example, calling `update_cat_dict(catalog, Item("Radio", 8))` would have no effect whereas `update_cat_dict(catalog, Item("Phone", 540)` would add the key-value pair `"Phone": 540` to `catalog`).

**Task B-2:** Write a function called `test_update_cat_dict` that sets up *one* example dictionary but calls `update_cat_dict` multiple times and verifies the described side effects. Again, you are **not** writing `update_cat_dict` itself, so you won't be able to run this test.

**Task B-3:** Now let's think about how else we can reason about testing. The tests you worked on in task B-2 are a good start, but sometimes we want to run more comprehensive tests on real-world data. Let's assume that someone has given us a large dictionary to test with. Fill in the assertion parts of the following testing function. This is a bit different from the example we saw in lecture, because we don't know *exactly* what our testing data looks like. Think about the assumptions you can and cannot make about `large_cat_dict` and what it will look like after each call of `update_cat_dict`. What can you ask *about* `large_cat_dict` in your assertions?

Start with this code. **Do NOT change the given lines, and do NOT make any additional calls to `update_cat_dict`**

def test_update_cat_dict_large():
    # SETUP
    shoe1 = Item("Sneaker", 45)
    shoe2 = Item("Sneaker", 32)
    # the variable large_cat_dict was defined elsewhere in the file
    
    # feel free to create variable(s) here or elsewhere in the function
    
    update_cat_dict(large_cat_dict, shoe1)
    
    # assertion(s) go here
    
    update_cat_dict(large_cat_dict, shoe2)

    # assertion(s) go here

Here are __some__ questions to keep in mind:
- Can you assume that a value is in the dictionary already?
- Can you assume anything about the shoe prices after the first call to `update_cat_dict`? What about the second call?
- What do you want to make sure of after each call to `update_cat_dict`, regardless of what was in the original `large_cat_dict`

Even though the test data (`large_cat_dict`) is defined for you, you can create variable(s) to help you in your assertions. For example, you can access the value associated with a key in `large_cat_dict` if it helps (but make sure you're not making assumptions about whether the key exists already!).

## Handin
You will be submitting two separate files to [Gradescope](https://www.gradescope.com/courses/1103553) under Homework 6 -- note that you're not submitting a code file!
- `tracing.pdf` with your answers to the "Memory Tracing" section exercises
- `test_hw6.py`, which will contain the testing functions from the "Testing Under Mutation" section

## Theme Song
### [Learning to Fly - Pink Floyd](https://www.youtube.com/watch?v=nVhNCTH8pDs&list=RDnVhNCTH8pDs&start_radio=1)

## Staff Spotify Playlist
### <iframe style="border-radius:12px" src="https://open.spotify.com/embed/playlist/6HiBE5A4YvHZHC5jwxZYoe?utm_source=generator" width="100%" height="352" frameBorder="0" allowfullscreen="" allow="autoplay; clipboard-write; encrypted-media; fullscreen; picture-in-picture" loading="lazy"></iframe>

------
> Brown University CSCI 0111 (Fall 2025)

<iframe src="https://forms.gle/avVrN7H8u6hjiH8j7" width="640" height="372" frameborder="0" marginheight="0" marginwidth="0">Loading…</iframe>