I had a great time at this year’s ICER conference – met up with some old friends and talked with some new ones about all sorts of CS education stuff. I also published a paper entitled Undergraduate Conceptions of the Field of Computer Science:

Students come to CS from a variety of backgrounds and with a variety of preconceptions. Some initially select CS with a very vague idea of the field they are majoring in. In this paper, I describe CS undergraduates’ view of the field of Computer Science. The approach was qualitative and cognitive: I studied what students think CS is and how students reasoned about their courses and curriculum. Through the use of grounded theory in 37 qualitative interviews with students and student advisors, I extracted three different conceptions about CS found in undergraduate CS majors using Grounded Theory. Overall, students had reasonable views of CS at a high level but lacked specifics. Students had difficulty describing subfields of CS or anticipating the content of courses they selected.

So in my quality assurance course, I ask my students to form groups of 2-3 and build computerized versions of board games. I selected board games in particular because I knew board game logic was both understandable AND tricky enough that it could generally benefit from robust unit testing (which was what I was mainly asking them to practice for this project).

I was very happy with what my students produced. Every team worked well and reliably turned out code week after week – perhaps partly because they knew I was monitoring their github commits đź™‚ . These games are really quite complex…if you look at these videos I think you’ll see tons of detailed (and tricky to implement) logic.

And…lest you think I was slacking on the testing…each of these games has greater than 75% code coverage…not at all bad when you consider the complexity of the GUIs which are mostly untested.

I’m a big believer in student feedback. Even though students often can’t articulate the source of problems, going through and reflecting is an essential part of figuring out what I want to try going forward. So even in an environment like GHP where I’m not asked to formally collect evaluations, I always do. Of course, it really helps that at GHP in particular students are relentlessly positive. Seriously my worst review this summer was “not my favorite class by any means, but still good”. I wish that’s what my worst university eval looked like.

BUT, looking at the feedback (here and here), one thing that I am struck by is how much more satisfied by student feedback that is about course content and not about me. This is something that I think the Wicked Teacher of the West said first…but I can’t find the blog post now. When I student says “It’s a really great course” that of course makes me a little happy. But when a student says “I thought it was really neat how you could prove problems are incomputable by reducing them to other incomputable problems” that makes me think I did my job. It’s always about the student’s relationship with the content, not the student’s relationship with you.

I see that a lot more in my theory of computation course than I do in my fractals class – that makes me suspect I’m doing a better job in ToC.

Theory of Computation was different this year, I think because I didn’t have the same core of super-strong students who were really loving the course. There’s definitely a class culture that develops, and I’m not yet attuned enough to think seriously about how I can help its development. The course was still good, and I think I was able to smooth out some rough edges for some students. Remaining challenging however, is the issue of the two main proof techniques we do in class: the pumping lemma and incomputability proofs. If I teach this course again I’m gonna at least crack the pumping lemma.

Fractals was better this year. I found it less stressful, and I think the students learned more. Fractal dimension seemed like a big hit this time around, so I we can explore that a little more. We kicked things off with some very simple feedback functions and Chaos – I think that helped people get on board at the get go. I think affine transformations needs more exploration discussion and play. A little tricky without computers some times.

I wanted to have the color of my term-mode mode line switch, depending on whether I was in character mode or line mode. I’m not sure why this became an overwhelming desire of mine, but it did. Not really knowing anything about emacs font faces, themes, or anything I pulled up my debugger and started spelunking in color-theme-buffer-local. I discovered a mysterious function face-remap-add-relative designed to do exactly what I wanted – let me remap a particular part of a single buffers theme and then undo that mapping when finished.

A smarter person might have checked the emacs manual and saved himself a lot of time.

Here’s how it works:
;; set the modeline background color and save a "cookie" so the change can be undone
(setq old-term-color (face-remap-add-relative 'mode-line :background "dark goldenrod"))

;; undo that change later
(face-remap-remove-relative old-term-color)

Interestingly, I’m pretty sure this ability to change colors for a specific buffer is one of the new features of Emacs 24. Yay progress.

So I announced my defense today. It’ll be on November 2nd at 1pm in TSRB 132.

Here’s the abstract:

Computer Science is a complex field, and even experts do not always agree how the field should be defined. Though a moderate amount is known about how precollege students think about the field of CS, less is known about how CS majorsâ€™ conceptions of the field develop during the undergraduate curriculum. Given the difficulty of understanding CS, how do students make educational decisions like what electives or specializations to pursue?

This work presents a theory of student conceptions of CS, based on 37 interviews with students and student advisers and analyzed with a grounded theory approach. Students tend to have one of three main views about CS: CS as an academic discipline focused on the mathematical study of algorithms, CS as mostly about programming but also incorporating supporting subfields, and CS as a broad discipline with many different (programming and non-programming) subfields. I have also developed and piloted a survey instrument to determine how prevalent each kind of conception in the undergraduate population.

I also present a theory of student educational decisions in CS. Students do not usually have specific educational goals in CS and instead take an exploratory approach to their classes. Particularly enjoyable or unenjoyable classes cause them to narrow their educational focus. As a result, students do not reason very deeply about the CS content of their classes when they make educational decisions.

This work makes three main contributions: the theory of student conceptions, the theory of student educational decisions, and the preliminary survey instrument for evaluating student conceptions. This work has applications in CS curriculum design as well as for future research in the CS education community.

In my GHP Fractals class this summer, I opted to write my sample programs in R. I selected R because it has very nice graphing libraries and built-in complex numbers. Overall, I was pleased with R; it definitely let me built some incredibly straightforward fractal code. It’s not as fast or pretty as other choices might have been, but it highlighted the underlying math which was most important to me.

King's Dream Strange Attractor (parameters from Chaos In Wonderland)

.

You can see an example on the left, rendered by R. The source of this particular fractal comes from Clifford Pickover’s Chaos in Wonderland. The graph is made by repeatedly iterating a simple function of x and y based on sine and cosine.

You can see the code in R here:

a <- -0.966918
b <- 2.879879
c <- .765145
d <- .744728
pointsToPlot <- 100000
x <- .1
y <- .1
allXs = rep(0,pointsToPlot)
allYs = rep(0,pointsToPlot)
for(i in 1:pointsToPlot) {
newx <- sin(y*b) + c*sin(x*b)
newy <- sin(x*a) + d*sin(y*a)
x <- newx
y <- newy
allXs[i] <- x
allYs[i] <- y
}
plot(allXs, allYs, pch=".", col="red",
main="Strange Attractor: King's Dream")

Here’s a few more pretty pictures:

King’s Dream Strange Attractor from Chaos In Wonderland by Pickover

The henon attractor

A julia set

Fractal based on mobius transforms from Indra’s Pearls by Mumford Series and Wright

So Duke Spring 2012 is finished, and grades are in; it’s time for me to become an ordinary graduate student again. But before I do that, I think it’s reasonable to reflect just a bit on how the semester went.

All and all, I am happy but not ecstatic with how my first semester turned out. In general I think students enjoyed my classes and they learned a lot (and my course feedback reflects this). I was able to try out some techniques I thought would work well, and in general I had good success. Of course it also helped that my students were almost always enthusiastic and extremely conscientious.

One main thing I learned this semester is that I have to be a little bit more careful about how I manage my time outside the classroom. As a professor, there’s a lot I can do to help students and in the beginning it was really easy to put in a lot of extra hours. Not that I mind putting in extra hours for the students, but time away from relaxing and sleeping takes it’s toll. Towards the end of the semester, I just got exhausted and then I really couldn’t put in time sometimes when I really needed to.

Well, enough vagueness. Here’s what my students said in their written feedback, crudely summarized by me:

CS100 is a your basic CS2 course, providing an introduction to data structures, big O, and of course plenty of practice coding tricky problems. This course is a great favorite of mine to teach, mostly because of the office hours. It’s just fun to work with students who are just starting to get serious with Computer Science; they are still capable of having fun just getting the computer to output the right stuff.

For extra credit, we gave the student an opportunity to write a song about Computer Science. There were some super awesome submissions. One of my favorite lines is the refrain from this adaptation of Avril Lavigne’s Complicated (Noelle Suaifan):

Whyâ€™d you have to go and make Java so complicated?
I see the way you’re forgetting to import packages gets me frustrated
CompSciâ€™s like this, you
And you code and your program implodes and takes forever to load
and you donâ€™t insert that node and your code is the biggest mess
But promise me youâ€™re never gonna switch your major to Art History
No, no, no

This is a post not really about what I did, but what 3 of the high-school students I worked with did. I met Gil and Claus in my automata class at GHP this summer. As part of the summer research project, they worked on developing their own kind of automata and ended up with something similar to a Neural Network. This fall, Gil, Claus, and Anirudh contacted me and proposed continuing that research but expanding the neural network connection for the Siemens Science Competition. Although I agreed to advise them where I could, this project was basically completely done start-to-finish by Gil, Claus, and Anirudh.

What eventually came out of this project was an attempt to build a Neural Network capable of optimizing the parameters of other neural networks. As the paper says:

The fundamental goal of this project is to create a backpropagation neural network that can determine the optimal training parameters to train another neural network with a different goal based on only characteristics of the training data. Such a neural network has the capability of improving the accuracy and speed of the training process for backpropagation networks used for any application.

In order to accomplish this Gil, Claus, and Anirudh researched neural networks, programmed their own network framework from scratch, and attempted to design a neural network that could help optimize other neural network parameters. Unfortunately the result they got was that the intermediate network wasn’t able to optimize properly. My opinion is their approach still has merit, and whether or not they get back to this particular project I hope they weren’t too disappointed with the negative result. This was a very cool project that required a great deal of both math and Computer Science to accomplish.

So one of the coolest traditions at in Duke is CS149s. Officially, it’s called the problem solving seminar. Unofficially, it’s weekly preparation for ACM ICPC competition. Students work hard in this course: every week they work on a problem set consisting of old ICPC competitions or TopCoder. It’s no small part from this class that Duke has gone to the ICPC international competition every year but 1 since 1994 (something like that anyway…don’t quote me on that).

Coming to Duke for the first time and never having competed in ICPC myself, being handed the reins of this course was a little bit scary. But lucky for me I had two incredible TAs – Kevin Kauffman and Siyang Chen. They helped me a lot in understanding what kind of preparation would be important and I like to think that I helped them with the pedagogical approach to teach it. I definitely changed the course – I made topics more explicit, I required a minimum number of problems each week, and I added a new post-contest project.

This year, Duke continued its streak by placing first in its region. My winning team was Jie Li, Yuqian Li, and Joe Keefer. I would like to claim some partial credit for that, but I’m pretty sure it’s strictly their own natural awesomeness. What I am especially happy about is that every Duke team managed to get 3 problems this year – including teams with non-majors and folks in intro CS. Everyone worked this year and I think it showed.