Lessons Used in This Pathway

Students use the options on CODAP’s Configuration menu to produce displays and plots of the Animals Dataset.

Where have you seen infographics and graphs used to display data in the real world?

Open the Animals Dataset in CODAP.

🖼Show image

If students report that a blank graph appears (rather than a scatterplot), prompt them to whitelist CODAP on their ad-blocker. Ad-blockers do seem to inhibit some of the functionality of CODAP (which will fortunately never advertise to users!).

Initially, the data points are randomly distributed on the graph. Selecting an orange dot reveals the name of that particular animal. Selecting a particular dot causes the table row for that animal to be highlighted in blue. Holding the shift button allows students to select multiple dots in the graphical display, or multiple rows in the table.

Students should observe that when they select a table row (or multiple table rows), the corresponding dots change from orange to turquoise. When they set aside selected and / or unselected cases (by using the "eye" icon), they can temporarily alter the amount of pets in the dataset (with the option to restore to the original dataset).

Students can also resize the window by dragging its borders.

Once we have a graph of randomly distributed data points, we can organize the data by selecting attributes from our table that we want to appear on the axes of our graph.

Experiment with creating some bar charts in CODAP by following the steps below.

To dig deeper into bar charts, have students turn to Bar Chart - Notice and Wonder.

Bar charts look a lot like another kind of chart - called a "histogram" - which are actually quite different because they display quantitative data, not categorical. Making a histogram in CODAP, however, begins quite similarly to making a bar chart in CODAP - by creating a dot plot that will be modified.

Bar charts display how much of the sample belongs to each category. If they are based on sample data from a larger population, we use them to infer the proportion of a whole population that might belong to each category.

While bars in some bar charts should follow some logical order (alphabetical, small-medium-large, etc), they can technically be placed in any order, without changing the meaning of the chart.

Students freely explore the CODAP data display options available to them when they select the bar graph icon (also known as the Configuration menu). In doing so, they experiment with new charts and get comfortable with CODAP as a platform for doing data science.

There are lots of different kinds of charts and plots. Even if you don’t know what these plots are for yet, see if you can figure out how to use them.

There are many possible misconceptions about displays that students may encounter here. But that’s ok! Understanding all those other plots is not a learning goal for this lesson. Rather, the goal is to have them develop some loose familiarity.

Today you’ve added more data displays to your toolbox. You can create bar charts to visually display data, and even transform entire tables!

You will have many opportunities to use these concepts in this course, by applying what you’ve learned to answer data science questions.

Students sort a column on a table by actually changing the table.

Open the Animals Dataset in CODAP. How many animals' names start with the letter M? What would make it easier to figure out how many animals' names start with the letter M?

Student work in groups or pairs. They will sort various columns on the table by clicking the attribute name, and selecting from the drop-down menu either Sort Ascending or Sort Descending.

Using the Sort Transformer, students sort rows of a table in ascending or descending order, according to one column. When they use transformers, students are building and modifying a copy of the original table.

🖼Show image

The Transformers plugin allows students to transform datasets to produce new, distinct datasets, rather than modifying the original input dataset itself.

First, show students how they can access the Transformers plugin (see screenshot on right), and invite them to explore the different Transformers available.

Explain to students that the Sort Transformer consumes: (1) a dataset; (2) a formula; (3) the type that the formula evaluates to; and (4) a sort direction (ascending or descending). But what does it produce?

Students may be more familiar with filters that actually change the table. In CODAP, all transformers produce a brand new table. Filtered tables are automatically saved; CODAP titles each new table with a number in curly braces at the end (for example, Filter(Animals-Dataset) {1} ) to indicate how many times the transformer has been applied. When students apply a transformer, they have the option of selecting the original table from the dropdown menu, or a new table that they’ve generated. Students can also rename saved tables, if they’d like.

Students learn how to filter tables by removing Rows.

Explain to students that you have "Function Cards", which describe the purpose statement of a function that consumes a Row from a table of students, and produces a Boolean (e.g. - "this student is wearing glasses"). Select a volunteer to be the "Filter Transformer", and have them randomly choose a function card from from the Function Cards set, and make sure they read it without showing it to anyone else.

Have 6-8 students line up in front of the classroom, and have the filter transformer go to each student and say "stay" or "sit" depending on whether their function would return true or false for that student. If they say "sit", the student sits down. If they say "stay", the student stays standing.

Ask the class: based on who sat and who stayed, what function was on the card?

Suppose we want to get a table of only animals that have been fixed? The Filter transformer consumes a dataset to filter and a formula expression that evaluates to either true or false.

The Filter Transformer walks through the table, applying whatever formula it was given to each row, and produces a new table containing all the rows for which the formula returned true. Notice that Filter takes a dataset and produces a copy of it that contains only the cases for which the given formula evaluates to true. If it consumes anything besides a single Row, or if it produces anything else besides a Boolean, we’ll get an error.

Debrief with students. Some guiding questions on filtering:

Students learn how to build columns, using the Build Attribute transformer.

Suppose we want to transform our table, converting pounds to kilograms or weeks to days. The Build Attribute transformer makes a new copy of a dataset, and adds a new attribute. We must provide a dataset, a name for the new attribute, an existing collection to add the attribute to, a formula for the attribute’s values, and an indication of the type of value the formula will evaluate to.

The Build Attribute Transformer walks through the table, applying whatever formula expression it was given to each row. Whatever the formula expression produces for that row becomes the value of our new column, which is named based on the string it was given. In the first example, we gave it Age < 5, so the new table had an extra Boolean column for every animal, indicating whether or not it was young.

Debrief with students. Ask them if they can think of a situation where they would want to use this. Some ideas:

Being able to define is a huge upgrade in our ability to analyze data! But as a wise person once said, "with great power comes great responsibility"! Dropping all the dogs from our dataset might be a cute exercise in this class, but suppose we want to drop certain populations from a national census? Even a small programming error could erase millions of people, impact funding for things like roads and schools, etc.

Students practice more of what they learned in the previous lesson, applying the Design Recipe to make table functions that operate on rows of the Animals Dataset. These become the basis of the chaining activity that follows.

The Design Recipe is a powerful tool for solving problems by writing functions . It’s important for this to be like second nature, so let’s get some more practice using it!

Did students find themselves getting faster at using the Design Recipe? Can students share any patterns they noticed, or shortcuts they used?

Students learn how to compose multiple table operations (sorting, filtering, building) on the same table - a technique called "chaining".

Now that we are doing more sophisticated analyses, we might find ourselves writing the following code:

That’s a lot of code, and it also requires us to come up with names for each intermediate step! Pyret allows table methods to be chained together, so that we can build, filter and order a Table in one shot. For example:

This code takes the animals-table, and builds a new column. According to our Contracts Page, .build-column produces a new Table, and that’s the Table whose .filter method we use. That method produces yet another Table, and we call that Table’s order-by method. The Table that comes back from that is our final result.

It can be difficult to read code that has lots of method calls chained together, so we can add a line-break before each “.” to make it more readable. Here’s the exact same code, written with each method on its own line:

Suppose we want to build a column and then use it to filter our table. If we use the methods in the wrong order (trying to filter by a column that doesn’t exist yet), we might wind up crashing the program. Even worse, the program might work, but produce results that are incorrect!

As our analysis gets more complex, chaining is a great way to re-use work we’ve already done. And less duplicate work means a smaller chance of bugs. Chaining is a powerful way to work, so it’s critical to think carefully when we use it!

Statistical inference involves looking at a sample and trying to infer something you don’t know about a larger population. This requires a sort of backwards reasoning, kind of like making a guess about a cause, based on the effect that we see. To better understand the process of going from the sample back to the population, it helps to understand the more straightforward process of going from the population to a sample. If the sample is random, we call this process Probability!

In real life we typically don’t know what’s true for an entire population. But this probability thought-experiment will start with a larger population with known properties (such as the fact that nearly half of the entire population are males). Then we’ll see what kind of behavior we tend to see in random samples taken from that population.

One of the most useful tasks in Data Science is using sample data to infer (guess) what’s true about the larger population from which the sample was taken. This process, called statistical inference, is used to gain information in practically every field of study you can imagine: medicine, business, politics, history; even art! Early on, statisticians discovered that random samples almost always work best.

Suppose we want to estimate what percentage of all Americans plan to vote for a certain candidate. We can’t ask everyone who they’re voting for, so pollsters instead take a sample of Americans, and generalize the opinion of the sample to estimate how Americans as a whole feel. But choosing a sample can be tricky…​

Sampling is a complicated issue. The main reason for doing inference is to guess about something that’s unknown for the whole population. But a useful step along the way is to practice with situations where we happen to know what’s true for the whole population. As an exercise, we can keep taking random samples from that population and see how close they tend to get us to the truth. Another discovery (besides the value of randomness) that statisticians made early on was something that’s perfectly consistent with common sense: Larger samples are better than smaller ones, because they tend to get us closer to the truth about the whole population.

Let’s see what happens if we switch from smaller to larger sample sizes, if we’re taking a random sample of shelter animals to infer what’s true about the larger population…​

The Animals Dataset we’ve been using is just one sample taken from a very large animal shelter. How much can we infer about the whole population of hundreds of animals, by looking at just this one sample?

Many people mistakenly believe that larger populations need to be represented by larger samples. In fact, the formulas that Data Scientists use to assess how good a job the sample does is only based on the sample size, not the population size.

Have students share. Were larger samples always better for guessing the truth about the whole population? If so, how much better?

This activity is all about grouped samples: Students make a bunch of subsets from the Animals Dataset, and see how each subset might answer the same question differently.

When looking at a scatter plot of our animals, it looks like the amount an animal weighs may have something to do with how long it takes to be adopted. 🖼Show image

But if we label the dots by animal, we notice every data point after 25 pounds belongs to a dog from the shelter! The cats are all clumped together in the lower weight range, making it hard to see how weeks to adoption may relate to a cat’s weight.

🖼Show image

Divide the class into groups of 3-4, with one student identified as the "reporter".

Have the reporters share their findings with the class.

Imagine that you’ve been handed a dataset from a country where half the people are wealthy and have access to amazing medical care, and the other half are poor and have no healthcare. If we took a random sample of the population as a whole, we might think that they are generally middle-income and have average health. But if we ask the same question about the two groups separately, we would discover inequality hiding in plain sight!

Ultimately, it might make more sense to ask certain questions about "just the cats" or "just the dogs". Averaging every animal together will give us an answer, but they may not be useful answers.

Data Scientists define grouped samples of datasets, breaking them up into sub-groups that may be helpful in their analysis.

Earlier, you learned how to define values in Pyret. We can define Numbers, Strings, Images, and even rows:

Let’s use this skill to define Tables…​

We already know how to define values, and how to filter a dataset. So let’s put those skills together to define a grouped sample of the dogs in the shelter:

Debrief with students. Thoughtful question: how could we filter and sort a table? How can we combine methods?

Students revisit the data display activity, now using the samples they created.

Making grouped and random samples is a powerful skill to have, which allows us to dig deeper than just making charts or asking questions about a whole dataset. Now that we know how to make subsets, we can make much more sophisticated displays!

Were any of the students' displays interesting or surprising? Given a novel question, can students identify what helper functions they would need to write?