Whaddya know? Math in the "real world"!

I've been helping out a bit with the FIRST Robotics team at my school. By "helping out," I really mean learning a ton from the kids and the amazing advisor (I really couldn't have told you the first thing about building a robot a month ago), and occasionally being useful on the programming side of things. Last Saturday, we were writing the code (in a program called LabVIEW, a "graphical development environment") to make the robot's two motors spin in various directions in order for it to move forwards, backwards, and turn right or left when the driver moves the joystick accordingly. After banging our heads against the wall with "if" statements and such, we realized that what we were really trying to do was a simple rotation/change of coordinates - enter linear algebra!

The joystick has two axes: let's call the horizontal axis A1 and the vertical axis A2 (see diagram). The program can read one input from each axis, so in the extreme case if the driver is pushing the joystick forward as far at it will go but not moving it side-to-side at all, the "coordinates" of that move are (0,1). Similarly, moving the joystick completely to the right but not forwards or backwards at all gets read as (1,0).

Now, of course all of this information has to get sent to the motors somehow. There is one motor on each axle of the robot, which we'll think of as the left motor and the right motor. In motor-land, the coordinates will be (left motor, right motor). We figured that in order for the robot to go forward, both motors need to spin forwards. In other words, (0,1) in joystick-land should correspond to (1,1) in motor-land (see diagram below). Similarly, (0, -1) in joystick-land means we want the robot to move backwards, so that would be 

(-1,-1) in motor-land since both motors need to spin backwards. To make the robot turn to the right -- (1,0) in joystick land -- the right motor needs to spin forwards while the left motor remains still, so that would be (0,1) in motor-land. So you can see that it was really a matter of reading off the coordinates in joystick-land and transforming them over to coordinates in motor-land, as in the chart.

Knowing that a change of coordinates simply corresponds to a matrix transformation, we just had to figure out the matrix. That turns out to be really simple because of all the zeros and ones; for example, setting up one of the matrix equations:

tells us that b=1 and d=1. The others tell us that a=0 and c=1. So, we've figured out that when the program reads input from the joystick as (A1,A2), we want those coordinates to get multiplied by the matrix we found before getting sent to the motors. This means:

which tells us exactly what to do with the input from the joystick before sending it over to the motors! 

I loved everything about this - the fact that transformations and matrices just "came up" when we were actually solving an interesting problem, the fact that I was able to explain this to the programmer on the robotics team (a 10th grader who had never seen matrices before), and the fact that the solution turns out to be so simple. What kills me is that I spent a month last year doing matrices with my 11th graders via some marginally interesting linear programming problem that didn't necessarily get at the essence of what matrices are. I know how I'll be teaching matrices in the future!

Maybe this will rile up your geometry class

I was reading this awesome unit on "other dimensions" courtesy of Mathematics Illuminated. In it, they make the following deceptively simple observation:

If we take two points in 1-D space and connect them, we form a line segment. This line segment has a property that no single point has, length. The length of a line segment in 1-D space can be found from the positions of the two endpoints via subtraction. 

But if no single point has length (instead, it is defined only by a location), yet a line segment consists only of single points, how is it that a line segment itself has measurable length? 

Of course this isn't really a paradox once we introduce infinity and stop trying to interpret infinity as just "a really big number" with all the same properties as numbers. The segment contains infinitely many points, so apparently infinity*0 is not zero (unlike "numbers" we are used to, all of which satisfy the property that: # times zero is zero). A beautiful revelation just waiting to be plucked from an awfully dry geometry standard.

From experience, my kids love talking about infinity in all its forms. Maybe yours will too!

Is programming the new math?

This past semester I taught a programming elective for seniors We used Python because it's already installed on all of the school computers and we have a resident Python expert who I could turn to for support.To be honest, I didn't have very much programming experience before the class began. I had taken a C class in grad school when I was too sick of math to care about my research, and that's the only formal programming I had done. This summer I taught myself some Python using this fantastic book by Michael Dawson, which teaches the basics through programming games. By the end of the summer, I knew enough to plan the first couple of months of class. I was unsure of my own programming abilities, let alone my ability to teach programming.

When all is said and done, this may have been my favorite class this semester. It turns out that programming is just so much fun that students can't help but get engaged, which is a far cry from what usually happens in math class. Sure, we can make math fun with activities, and once in a while you hit upon a topic or a problem that kids are naturally drawn to. But much of the time I would loosely equate teaching math with pulling teeth, and programming couldn't be more different.

There was certainly a learning curve to my teaching. I'll spare you the messy details and cut to the chase:

• I learned to minimize lectures. Kids (and all people) learn programming by doing. Giving them a few examples to follow and execute on their own is much more effective than parsing code as a class in lecture format (at least with my group, which tended to get squirrelly really quickly).
• When I did lecture, I used PowerPoints that the students could upload onto their laptops so they could follow along at their own pace. I also tried to include as many opportunities as possible for them to try out commands along the way. I finally started getting the hang of this when we were doing Visual Python; see my lecture notes here if you are interested.
• Tiered programming assignments rock. There are easy, medium, and hard programs in a single assignment. Students choose whichever ones they want and aim for a certain total point value. Harder programs are worth more points. See my programming assignments here if you are interested.

Something that became obvious very quickly (and was integral in quelling my fears that I was under-qualified to teach a UC-approved programming class) is that almost every student in the class was into it. This was bizarre, having a class where 25 out of 27 students were really trying to figure out a problem and would literally groan when I told them they had to shut down their computers at the end of class. This shouldn't have been a surprise; I also find myself so engrossed in programming that I don't even notice that several hours have passed. I guess I forget that students are just like us - they like things that are inherently interesting, and dislike things that aren't.

Programming is great - it's hands-on, there's the "wow" factor (even early on, when kids can add up all the numbers from 1 to 1000 in a second!), and most importantly there's an element of immediate gratification. Oftentimes with math there's this fuzzy feeling students have when solving a problem ... ["Am I doing this right?" / "Do you think you're doing it right?" / "I thought so, but it looks really weird."] or ["Is this the right answer?" / "Looks like it!" / "Oh, so that's it?"] ... of course there are exceptional problems whose answers are so beautiful as to be undoubtedly correct, even from students' perspectives, but for the most part students struggle with knowing whether they are on the right track and whether they have solved a problem. In programming, there is no such ambiguity. They are "right" when their program does what it's supposed to do, and they can check their steps along the way simply by executing their code.

Moreover - and this is risky for me to say, because if this sentiment went viral I'd no longer have a job - it seems pointless to be teaching kids math en masse when we could be teaching them more programming instead. Our "justification" for making kids suffer through 12 years of math when most of them will never "use" math beyond algebra (of course this is a gross oversimplification. Statistics, for example, should and could be used by everyone and it's not clear whether this comes "before" or "after" algebra ... Despite what the state standards would have you believe, there is no total ordering on the set of math concepts) is that in enhances their quantitative thinking skills, teaches them creativity, and gives them experience solving difficult problems using out-of-the-box thinking. I buy that, I really do. I love math and I've seen the amazingness that happens when students collaborate on a challenging math problem. However, this can be a rarity in the math classroom. So much time is spent on skills that some find interesting and some find worthy of eye-gouging, yet whatever you believe you have to admit that fewer than 1% (an admittedly unfounded estimate) of adults will ever use any of the algebraic manipulations or shortcuts they learn in math class. Do they use the creativity and problem solving? Maybe. But programming might be a better way to go about cultivating those less black-and-white skills. It involves all of the logical thinking, all of the precision, all of the creativity -- yet without the tedious rules and algebraic manipulations that many students (rightfully) find mind-numbing.

I don't think we should cancel all math classes tomorrow. But I do think there's something behind the following observation: even those kids in my programming class who are not mathematically-inclined and/or completely disengage in math class, were engaged for a majority of the time in programming. And over the course of the semester, I saw a definite improvement in their ability to think logically and focus for long enough to try several strategies for solving a single problem. This is something I tried to get them to do in math last year, yet never felt terribly successful. In programming, I didn't even have to try very hard for them to accomplish those things.

One more thing: I was absolutely amazed by what my kids were able to do by the end of the semester. Most of them literally had no idea what programming was when the semester began, yet for their final projects they created programs that were pretty complex! Some examples of student work follow. All of these are interactive games made in VPython (Visual Python). (In retrospect, I might have taught VPython from the beginning. Even the few stragglers who weren't really engaged in programming at the beginning couldn't help but get into it when we started the visual stuff.)

A soccer game where the player controls the blue goal and the
ball moves randomly about the field

A classic 2-player game of dots & boxes (one
surprising challenge associated with this game is having
the computer recognize when a player has won)

A car game where the user has to navigate the red
"car" around a series of moving obstacles

An asteroid field where the user controls the
space ship and tries to avoid oncoming asteroids

If you have any say in this whatsoever, teach your kids programming! (Even if that means you teach yourself programming along the way.) Python is free and open-source and available for download here. Also check out a bunch of great resources for teaching programming.