The Problem

Chris wants to design a bean bag toss game and proposes the following schematic.  How would Chris figure out the probability of a bean bag going through one of the green openings if it is thrown randomly at the board?

This is the type of application problem typical of a high school geometry class.  Traditionally, such a problem occurs at the end of a unit on geometric measurement after students have been told and have practiced key formulas for triangles, circles, trapezoids, etc. But how can computer science (CS) serve as a vehicle to make such a problem (and generally, probability) more student-centered and dynamic?  Equipped with CS, let’s explore what I did in my class to enliven this topic.

Using JavaScript

Students bring a wealth of knowledge of probability to any geometry course. Part of this knowledge is academic where students have had previous math courses that introduce them to definitions or formulas. But moreover, students have their own experiential knowledge outside of the classroom that build, support, or sometimes refute these academic concepts. I wanted a way of using programming for students to connect the theoretical side of probability to the experimental. Enter JavaScript!  I wrote up some code that you can find here that allows students to collect meaningful data that would otherwise take a lot of time to collect by running an experiment by individual trials. The code simulates throwing pointwise bean bags repeatedly at the diagram above while displaying a running probability of success, namely, tossing a bean bag through a hole. Before running the simulation, students were asked to estimate this probability of success.  After observing the simulation, they compared their estimate with the simulation’s value (approximately 17%). Then they were to try to find this probability a different way, which can be calculated theoretically by an area argument. The calculation below is in line with what students observed from the simulation. Some astute students noticed that this calculation assumes we at least hit the board and that we are neglecting the size of the bean bags:

A quick program allowed students to interact with a simulation to collect meaningful data to connect to a theoretical approach. Moreover, such a program embeds the concept of a limit that many students will see later in Calculus.  In fact, a few students were interested in looking at the code behind the scenes, one noticing that codes on lines 28 to 31 are related to the Distance Formula, checking if a given point is within a certain threshold distance. The first two variables determine if a selected point (x, y) is within the interior of one of the two circles.  The second two determine if the selected point (x, y) is within the triangle or rectangle.

I wanted students to be able to modify the shapes on the target to effect the probability but few students had a background in JavaScript to make shapes and check if points were interior to them.  Enter Scratch!

Using Scratch

Scratch is an easy interface to use with students who have not necessarily had previous programming experience. It works nicely with object detection, such as determining if one object (or sprite) is touching another. For students to simulate their own bean bag toss, game they were directed to this Scratch project, motivated by a Twitter post by Patrick Honner about Monte Carlo Simulation.  Click “See Inside” in the upper right corner to look at the code.

Students were asked to analyze the code and give a rough verbal description to a partner about what they think would happen.  They were then asked to run the code with the green flag and to make observations about the output.  They could hit the green flag again to see how the output changed. With each green flag press, 25 experiments are run, each randomly throwing 5000 points at the canvas. The resulting probabilities of hitting the blue circle for each of these 25 experiments is displayed as a list along the right of the screen. Similar to the JavaScript demo, students can approximate the experimental probability via the output while also observing some variability across trials. 

Students were asked to compare the experimental probability estimates to the theoretical, which can be computed knowing the amount of pixels for the screen and the circle.  By clicking “stage” in the bottom left and then “backdrops”, students can access the blue circle. The window dimensions are 480 pixels wide by 360 pixels tall while the circle is approximately 156 pixels in diameter.  The theoretical probability of landing in the blue circle is then

very close to our experimental estimate!

To conclude, students were asked to make their own backdrop design (either using the same color blue or changing the code to be of their new color) so that the probability is closest to 30% as possible.  Students can select the color that they wish to touch by clicking on the color in the code then selecting the color from their backdrop using the eyedropper tool. Students could not only test their design experimentally using the provided code, but were also encouraged to compare this to the theoretical probability depending on their design.  An example of a student design is shown below. Students used strategic thinking and refinement to get as close to 30% as they could while personalizing their design.

Summary

In closing, it is my hope that these examples have enlivened your interest in the intersection of math and CS.  Not only does CS provide students to gain access to running simulations that would otherwise take lots of time to do physically – it provides a space for students to conjecture, experiment, and reason.  Give this activity a shot or tweak it to fit your students’ interests and needs. 

,

Guest Blogger: Chris Bolognese (@eulersnephew)