For the past few Fridays, I have been teaching my first ever lessonsto a class of Norwegian students, and I wanted to write about the experience here.

This class was a class of 30 or so Norwegian students in Mathematics 1T, which covers the the topics of precalculus and differential calculus. The students in this course had just finished studying functions, and function notation.

I asked students about their previous programming experience—many students had done some programming in scratch, one had done some work in HTML, and none had any experience in Python.

Here is initial throught thought about how to structure a series of lessons for incorporating programming into math class. Students are already quite comfortable with calculators like Desmos and Geogebra, and readily see their utility in mathematics. Why not introduce Python as a sort of “build your own calculator,” emphasizing their ability to program their own functions that will be useful for future work?

Ideally, I could imagine that students in an Algebra 2 or Precalc class build a file of functions that would be useful for their own work in mathematics—functions to find the x-intercept of a line, the roots of a quadratic, or even the slope of a fuction at a point. Once students learn to master a procedure, they then develop that procedure into a function in Python, and later, are free to use that function on future assignments.

For this type of introduction, I decided to start students off in the Repl.it web programming environment. If you have internet connectivity in your classroom, Repl.it is a great environment to work with because there’s nothing to install or configure, and yet you get the exact same Python interface you would get from installing IDLE or Anaconda (without having to wait half an hour for Anaconda to download).

The other choice I made  was to start by working directly with the Python interpreter, rather than writing actual Python scripts. This requires students to enter commands where into the interpreter one at a time. After most commands, the interpreter gives you some feedback. So if you enter “3+7”, you’ll see 10 appear below the prompt. If you try to enter a command that requires multiple lines, like a function definition, the interpreter prompt switches to an ellipses “…” allowing you to enter each line of of the command. And if your line happens to include mismatching parentheses, you’ll be able to tell because Python won’t return to a normal prompt until the braces are matched. Finally, if you have any syntax errors in the line you wrote, you’ll get immediate feedback in the form of an error message right under the line.

I think there are a number of advantages to first working with the Python interpreter. In normal Python programming, where you are running a script, your errors appear in a separate window, and I’ve found it very hard for students to connect and interpret these error messages as having important feedback about their code. If you want to check the value of a variable, you simply need to type the variable name on its own line, and Python will print the contents of that variable. Working in the interpreter also gives you an opportunity to predict the output of each line of code before running it, which is also a valuable activity when first learning to program. And finally, for the exercise of building your own calculator, working in the interpreter feels much more like how a calculator actually operates.

## Lesson Plan

Every student brings up the a Python environment using repl.it on their laptop.

We start by entering some simple addition problems into the interpreter—”4+6″, and I ask them if they can figure out and check the other mathematical operations—subtraction, multiplication and division, and they quickly find “-“,”*” and ,”/”.

I then show them the “%” operator, and ask them to spend some time exploring what it does. I start by giving them some examples.

`5%3 --> 2`

6%3 –> 0

`10%3 --> 1`

I ask the students to spend some time exploring this operation. What are the possible outputs for this operation? What exactly is this operator doing?

Students make some interesting discoveries—the output is at most 1 less than the second number in the operator. When we get more systematic, exploring 1%3, 2%3, 3%3, etc, they see the output follow a cyclic patten. Eventually, students are able to predict the pattern from a few examples, and then with a bit more nudging, and some cross cultural discussion about the differences in division notation between Norway and the US (did you know that the US division sign functions as the minus sign in Norwegian? And long division on Norway looks completely different from how I was taught), they recognize the modulus operator that gives you the integer remainer from division.

At this point, I give them a cheat sheet of various python commands I pasted together from the internet and ask them to spend a few minutes exploring some of the examples in the cheat sheat. When we report back, students have discovered all sorts of neat things like

print(“Hello” * 2)

>”HelloHello”

### Defining functions

Since students had just studied function notion, and my ultimate aim was to help them build a library of useful functions for mathematics, I decided to introduce them to defining functions in Python.

Students see that function definitions in Python can look remarkably like mathematical function definitions. We start with a simple linear function.

``` def f(x):    return 2x+3 ```

Python also makes it pretty easy to create piecewise functions, like this

``` def f(x):    if x >= 0:        return 2x+3    else:        return 3 ```

Next, we talked about the difference between a variable and a parameter, and how in the code below, the x in the function is not the same as the variable x—this tends to be a very confusing concept for students who are just starting out with programming.

``` x = 3 def f(x): if x >= 0: return 2x+3 else: return 3 ```

This was pretty much the end of the first day of programming and 90 or so minutes of work. A week later, I came back with a Desmos activity I had created to help them test their ability to read code and understand basic Python operations. The first screen was a matching exercise where students matched 4 small 2 line programs with their output.

Then students took a crack at reading and predicting the output of a small program:

Thanks to the awesome computation layer, I was able to create a follow up screen that showed students what they wrote as the output and ask them to resolve any differences between their prediction and the output of the program.

Lastly, I created a simple slider for students to state how they felt about our work thus far:

Once we discussed their work on this Desmos activity, I wanted students to see how we can use Python to define functions that aren’t “mathematical” and so worked together to develop a function that would take an (x,y) pair as an input, and return the Quadrant that contains that point, I, II, III or IV.

We began this process by developing a small flow chart to help us think through the logic:

From this, I tried to do some interactive live coding where students would tell me what to write, and eventually, we put together a function that looked something like this.

`def Quadrant(x,y):`
`  if x < 0:    if y > 0:      return "I"    else:      return "IV"  else:    if y > 0:      return "II"    else:      return "III"`

``` ```

It was super helpful to have the flow diagram to go back to be able to show at various points in the coding how much of the function we had written. But as students were trying to follow along to write this program themselves, things went a bit off the rails. It was a bit of a jump to go writing code that had nested commands three levels deep, and I again found myself running around helping students make sense of all the various syntax errors they were being. Not good.

Sadly, class was just ending, so I had to leave with a lot of students feeling frustrated.

On the third day, I came back with another exercise to follow up on our work on the quadrant function. This time, I’d rewritten the code we discussed last time, adding a syntax error and a error in the algorithm, and asked students to spend the first bit of class debugging. This turned out be great. Students did a great job of finding the syntax error, and they were having productive discussions to try to figure out the bug in the program that was producing incorrect output. Many of them saw that debugging is way harder (and more interesting) than just finding syntax errors, and a few that finished early started to walk around the room to help out their peers.

Once we had a working Quadrant function, we started to create our own functions, lke this,

``` def f(x):    return x**2 + 4```

```print(Quadrant(2,f(2)) ```

to see how our function nicely predicts points along an whole variety of functions. We really started to have fun when the teacher suggested looking at the sine function, which I imported, and we could quickly see how our function’s predictions perfectly matched the graph of sin(x) in Desmos.

### Reflection

By the end of the third session, some students were really beginning to enjoy programming and thinking through the execution of a program. A few were still finding it pretty frustrating and wondering why programming must be so hard. This is something I really want to work on in the future in my own teaching. Much more than my experience teaching physics, students who begin to program seem to quickly separate themselves into people who develop a quick love for it and people who think it’s not for them. Often, I think this is tied deeply to a student’s previous experience with programming and programming adjacent activities, like taking things apart, working with simple machines, etc, and I would love for a way to help students who think programming is not for them because they aren’t getting it as quickly as their peers to see that often, their peers have had much more previous experience that forms much of the basis of their seeming “intuition.”

I also think there’s a real need to develop many small formative assessments for students who are programming, and to center most of these activities and assessments around reading code and making small modifications to scaffolded code. Too often, I think we ask students to write code from scratch, and not only is this something that rarely happens in the real world of programming, it is deeply challenging for students to work on translating their ideas for a program into an algorithm and then master all the tiny syntactic details necessary to get a working program. There are lots of strategies to help with this, like writing pseudocode, running your program often to find errors, but I think for some students, this still isn’t enough, and a few minutes trying to find your error in the 20 lines of code you just wrote in one sitting is a nearly impossible task.

Finally, I wonder if these assignments are dreadfully boring. It turns out that the Norwegian math curriculum barely addresses the notion of Quadrants, and I’m not sure that students are excited to build a library of functions they could use as their own custom built calculator as I would be. Certainly there are contexts, like working with vectors, calculating cross products and unit normal vectors where this idea might really help students to see just how powerful a Python driven calculator could be, but if we really want students to see the power of programming as a tool to explore mathematical thinking, I think we need to keep working to find better topics to explore.