Precalculus Task-Specific Programming for Building Image Filters from Matrix Operations (Precalculus TSP Part 1 of 5)

This is the start of a five part series of blog posts on Task-Specific Programming in Precalculus, subtitled “What Mark Did This Summer.” I wrote several blog posts in the Spring (last in May, linked here) about “task-specific programming languages.” I’ve been thinking a lot about them over the summer, and built my first prototypes for two task-specific programming environments. In these blog posts, I’m describing the two prototypes, and then considering the interaction with research on programming, on education, and on computing education research.

Both of my prototypes are built around teaching precalculus. My goal is to use computing to make precalculus less abstract and more relevant. I am inspired by Phil Sadler and Gerhard Sonnert’s work supporting the argument that precalculus is the most important set of concepts for students to succeed at college calculus (even more than high school calculus).  I want to provide a programming experience that can be used in five minutes which can be integrated into a precalculus class.

The first prototype is for constructing image filters from simple matrix manipulations that are part of many precalculus texts. In a digitized picture, each pixel has a red, green, and blue component (or channel) for its color. All the red values from the pixels can be described as a matrix for the red channel in the picture.

This is the opening screen for the prototype.

The image being manipulated is on the left. The list of matrix manipulations appears in the upper left. The manipulated image is on the upper right.

Across the bottom appear the matrices for the red, blue, and green pixels of this picture. A text description explains where these matrices come from. I tried hard to get the matrix representation close to what students might see in a precalculus textbook. That’s part of being able to be “integrated into a precalculus course.” The teachers I’ve shown this to have appreciated that attention — they don’t want to have to explain differences between the user interface and the textbook.

Changing the picture (see the button under the source picture), updates the matrices, the description, and re-runs the matrix transformation steps on the new input picture.

The lower right hand corner is an inspector to check individual pixel values. This was a suggestion from Line Have Musaeus from Aarhus when I demonstrated this prototype at ICER in Toronto. Precalculus teachers want students to understand how the math is working at the matrix-element level, so I give them a way to check individual matrix values. That’s when I added the block-color picture into the picture set — it makes it easier to understand the four quadrants, what the base colors are, and how the transformations change them.

Each of the matrix transformations appears on a separate card in a deck. Here’s one:

This transformation does a scalar multiplication of 0.5 (which the user sets by changing the text field in the statement). A pull-down lets the user pick which matrix they want to modify. When the user picks a matrix, the display in the lower left updates to show the new matrix. Again, I’m trying to get the formatting for scalar multiplication right from the textbook. The text description on the right updates to describe the selected transformation, and the text and matrix displayed on the lower right updates to show how that matrix is being transformed by this operation.

Here’s the other possible transformation (selected by radio button):

Here, we’re changing one of the channel matrices (pull down for red, green, or blue) to basic element-by-element arithmetic (addition or subtraction) of two selected matrices: red, green, blue, or a matrix of all-255’s. (I’ve had several suggestions to also provide the option of having a matrix of all the same number — all 1’s, all 0’s, or something like all-7’s).

I’m using a semi-transparent gray graphic to “hide” the unselected operation on the card. I want students to know that they can do either operation, so I don’t want it to disappear, but I want to show that it’s not selected.

Currently, the user presses the “Do It” button to process the individual transformations, or to do the whole program of transformations. You can have an arbitrary number of operations, and you can do some interesting transformations, like image negation:

Or making a scene look like it’s nearing sunset:

Press the Change Picture button to get a different input picture. So, the list of operations specifies a process which can be applied to an arbitrary input. It’s a program (for a specific task), but it’s not coding (an important distinction that Wil Doane pointed out to me at ICER this year).

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.