Skip to main content
Engineering LibreTexts

4.1: A Picture of Memory

  • Page ID
    39355
  • \( \newcommand{\vecs}[1]{\overset { \scriptstyle \rightharpoonup} {\mathbf{#1}} } \) \( \newcommand{\vecd}[1]{\overset{-\!-\!\rightharpoonup}{\vphantom{a}\smash {#1}}} \)\(\newcommand{\id}{\mathrm{id}}\) \( \newcommand{\Span}{\mathrm{span}}\) \( \newcommand{\kernel}{\mathrm{null}\,}\) \( \newcommand{\range}{\mathrm{range}\,}\) \( \newcommand{\RealPart}{\mathrm{Re}}\) \( \newcommand{\ImaginaryPart}{\mathrm{Im}}\) \( \newcommand{\Argument}{\mathrm{Arg}}\) \( \newcommand{\norm}[1]{\| #1 \|}\) \( \newcommand{\inner}[2]{\langle #1, #2 \rangle}\) \( \newcommand{\Span}{\mathrm{span}}\) \(\newcommand{\id}{\mathrm{id}}\) \( \newcommand{\Span}{\mathrm{span}}\) \( \newcommand{\kernel}{\mathrm{null}\,}\) \( \newcommand{\range}{\mathrm{range}\,}\) \( \newcommand{\RealPart}{\mathrm{Re}}\) \( \newcommand{\ImaginaryPart}{\mathrm{Im}}\) \( \newcommand{\Argument}{\mathrm{Arg}}\) \( \newcommand{\norm}[1]{\| #1 \|}\) \( \newcommand{\inner}[2]{\langle #1, #2 \rangle}\) \( \newcommand{\Span}{\mathrm{span}}\)\(\newcommand{\AA}{\unicode[.8,0]{x212B}}\)

    It’s easier with pictures at first, so we’ll draw plenty of them. Our memory pictures will have a very specific format, and this is crucially important: don’t get creative with how things are labeled or where things are drawn. In order for your code to work you must have this picture exactly right. It’s not art; it’s science.

    Our memory pictures will always be divided into exactly two “realms,” one on the left and one on the right, labeled as follows:

    clipboard_ef0205a3dac1235dbe78fe95bb798e313.png

    The left column’s name should be recognizable, since that’s exactly what we covered last chapter. The right column won’t have anything in it for a couple chapters.

    Writing to Memory

    When we create atomic variables in a Code cell, a la:

    Code \(\PageIndex{1}\) (Python):

    pin_count = 844

    username = 'Bekka Palmer'

    each one gets put on the left-hand side of the diagram as a named box. The name of the box is the variable’s name, and the thing inside of the box is its value.

    clipboard_ebfb8873c6d15b7d26f177eb12743d196.png

    It doesn’t matter which boxes are higher or lower on the page, only that the names stick with their boxes and don’t get mixed up. As a bonus, I have colored the boxes differently, indicating that pin_count (an int) is a different type than username(a str).1

    Creating more variables just adds more named boxes:

    Code \(\PageIndex{2}\) (Python):

    ...

    avg_num_impressions = 1739.3

    board_name = "Things to Make"

    clipboard_e5b8a20d6b63a5d7e7ab7faf385767ad5.png

    I’m deliberately shuffling around the order of the boxes just to mess with you. Python makes no guarantee of what “order” it will store variables in anyway, and in reality it actually does become a big jumbled mess like this under the hood. All Python guarantees is that it will consistently store a name, value, and a type for each variable.

    When we change the value of a variable (rather than creating a new one), the value in the appropriate box gets updated:

    Code \(\PageIndex{3}\) (Python):

    ...

    avg_num_impressions = 2000.97

    pin_count = 845

    another_board = 'Pink!'

    clipboard_e11e8e329b5add845c35c96426316ae5b.png

    Note carefully that the previous value in the box is completely obliterated and there is absolutely no way to ever get it back. There’s no way, in fact, to know that there even was a previous value different than the current one. Unless specifically orchestrated to do so, computer programs only keep track of the present, not the past.

    One other thing: unlike in some programming languages (so-called “strongly typed” languages like Java or C++) even the type of value that a variable holds can change if you want it to. Even though the following example doesn’t make much sense, suppose we wrote this code next:

    Code \(\PageIndex{4}\) (Python):

    ...

    pin_count = 999.635

    username = 11

    This causes not only the contents of the boxes to change, but even their colors. The username variable was a str a moment ago, but now it’s an int.

    clipboard_eaabf5862afeac8907876f0b377dbe083.png

    Reading From Memory

    “Reading from memory” just means referring to a variable in order to retrieve its value. So far, we don’t know how to do much with that other than print:

    Code \(\PageIndex{5}\) (Python):

    print("The {} board has {} pins.".format(another_board, pin_count))

    | The Pink! board has 999.635 pins.

    The important point is that the memory picture is the (only) current, reliable record of what memory looks like at any point in a program. Think of it as reflecting a snapshot in time: immediately after some line of code executes – and right before the following one does – we can consult the picture to obtain the value of each variable. This is exactly what Python does under the hood.

    I stress this point because I’ve seen many students stare at complicated code and try to “think out” what value each variable will have as it runs. That’s hard to do with anything more than a few lines. To keep track of what-has-changed-to-what-and-when, you really need to maintain an up-to-date list of each variable’s value as the program executes...which is in fact exactly what the memory picture is.

    So if you’re trying to figure out “what will this program output if I print the odometer variable immediately after line 12?” don’t stare at the code and try to reconstruct its behavior from scratch. Instead, draw a memory picture, update it accordingly as you walk through each line of code, and then look at it for the answer.

    Tip

    By the way, investing in a small whiteboard and a couple of markers is a great way to help you learn programming. They’re perfect for drawing and updating memory pictures as they evolve.

    Hopefully this chapter was straightforward. These memory pictures will be getting increasingly complex as we learn more kinds of things to store, however, so stay sharp!


    This page titled 4.1: A Picture of Memory is shared under a CC BY-SA 4.0 license and was authored, remixed, and/or curated by Stephen Davies (allthemath.org) via source content that was edited to the style and standards of the LibreTexts platform; a detailed edit history is available upon request.

    • Was this article helpful?