Archive for September 23, 2019

Building Textures from Waves: Debugging in Task-Specific Programming (Precalculus TSP Part 2 of 5)

The second prototype I built for Task Specific Programming in Precalculus is about using wave functions for building textures. As I mentioned in my last blog post, my goal is to use computing to make precalculus less abstract and more relevant. I want to provide a programming experience that can be used in five minutes which can be integrated into a precalculus class. In this prototype, I explicitly designed for inquiry and debugging. What would debugging look like in task-specific programming when the goal is learning precalculus and not programming or computer science?

I’m going to describe this one bottom-up. Wave functions are a common topic in a precalculus class (like in this YouTube lecture). These are typically taught in the form:

A sin(B(x-C)) + D


Amplitude sin(frequency(x-horizontalShift)+ verticalShift

I built a tool where the student specifies a wave function, then that wave is used to define a texture in terms of gray, red, green, or blue components.

This equation is plotted (lower right hand corner) where the X-axis controls the darkness. Each pixel is evaluated left-to-right, and it’s X-position is plugged into this formula. The Y value mapped to a gray scale. The plot should (if it all worked right, and it doesn’t really in this example) line up with the texture so that darkness and lightness maps to rise and fall in the darkness level of the texture.

Let’s set the “Challenge” section aside for just a few minutes.

We can map equations to other colors, and swap sine for cosine, and use the X or Y components of the pixel to determine the color. Like in the first prototype, each wave function appears on a separate card in a deck.

You can have an arbitrary number of these cards. When you get to the front page of the deck, you have a program of all the wave functions. These are then composed to create a more complex texture.

What does debugging look like here?

With this prototype, I thought more about the student’s process than I did with the image filter tool. In my work with both precalculus and social studies teachers, I’m increasingly thinking about inquiry, and I see debugging as a form of inquiry. You have some output, and you’re trying to understand it — and by “understand,” I mean being able to explain how the parts constitute the whole. The impetus to inquire (i.e., to debug) is that the output you have is not the output you expect or want. So, if we want to support inquiry as debugging, we have to support starting from a goal — an example, a requirement, or a set of tests.

I’m inspired by Diana Franklin’s group’s work on La Playa, a Scratch-like programming environment for 4th-6th grade students (see paper here). In La Playa, the programming tool opens up onto a starter file. The student could ignore it and just do open-ended programming, but more likely, the starter file guides the student and serves as a scaffold.

I made a prominent Challenge texture on the front page (and the challenge image appears on every wave card afterward). Can you make this? If you need a Hint, press the Hint button for a suggestion about is needed to make this texture.

In general, my challenge textures don’t really work. I built a bunch of cool textures to use as hints, like below, but the composition of color waves is one of the more complicated parts here — I talk more about it in Part 5 of the series.  But on the other hand, I showed some of these textures to researchers in culturally-relevant curricula who said that they reminded them of woven cloths from the cultures that they study.  Could we use wave functions in a form of culturally-relevant curriculum that blends precalculus and computing?

Imagine that you have a texture that you generated on the first page, and now you want to understand how your existing waves contribute to this texture, e.g, to figure out which equations need to be changed. One tool is the Pop button on the front Texture Program page. This pops out the texture into a separate window.

Now, you can drag the texture over the individual wave textures to understand how the pieces compose into the whole.

Each wave has a checkbox, so that the wave can be removed from the texture (without deleting), then put back in.

The idea is that a student can apply basic debugging principles: Compare to the example, find how this statement/computational-unit impacts the final outcome (like a print statement), and remove the statement/unit (like with a comment) to see the effect on the final outcome.

Multiple-linked representations

As I’ve shown this to math teachers, one of the things they like here are the multiple linked representations. We’ve got the equation:

When the student hovers, they get an explanation for each of the terms:

The plot and the texture, and if you press the “Points” button, you see exactly which points were plotted — both x,y on the graph, but also the computed x and y before they were mapped to the discrete points:

When I showed this to teachers, they wanted it to support more exploration. For example, they told me that students struggle to understand the difference between 3sin(x) and sin(3x). I was thinking that a useful addition to this tool would be a Bret Victor inspired scrubbing gesture over each of the terms in the wave function (as in his fabulous Learnable Programming essay, or in the Scrubbing Calculator). I want to be able to click on the “3” above, drag up, then move the cursor left or right to make that number less or more. As I scrub, I want to see the plot change and the texture change — but with some kind of shadow/echo so that I can compare the “3” plot/texture to the new values for “C.” Students can’t generally keep the original curve “in their head” when seeing the new one, so they need both to be visible to understand the effect of the equation change.

I built these in Livecode. The source file is available here. I’m also making binaries available for Macintosh and for Windows. (Yes, I can provide Linux, if someone’s interested.) These are provided with no warranty or guarantee — these barely do what I describe, and probably have lots of other mistakes, holes, weaknesses, and vulnerabilities. They’re slow as molasses. I strongly discourage you from using my prototypes with students. As I describe in Part 4 of this series, this is nowhere near where it needs to be in order to be useful.

September 23, 2019 at 3:00 am 10 comments

Enter your email address to follow this blog and receive notifications of new posts by email.

Join 9,052 other followers


Recent Posts

Blog Stats

  • 2,030,116 hits
September 2019

CS Teaching Tips