Tuesday, January 27, 2009

First Experience Reviewing a Paper

To help out a lab-mate, I agreed to review a conference paper last weekend. I was a bit nervous since I had never done this before, nor did I believe I was terribly qualified. Still, it was a good opportunity to change these facts, so I took it on.

My lab-mate gave me a really good article about refereeing to read. I found this paper refreshing, mostly because of its high quality writing (why does that seem so hard to find these days?). It was incredibly insightful, giving really good advice for how to review a paper, and at the same time, how to write a good paper yourself. It includes many questions to ask yourself about the paper you are reading (or writing). I highly recommend it for everyone in academia.

Armed with my newfound knowledge, I tackled the conference paper I was assigned. Fortunately, it was at just the right level, so I was able to fully understand what the authors were saying. I felt they had a good result, but that there were some serious issues with how they presented it.

The short summary is that they used up some of their four page limit early on in the paper for explaining some things that I don't think were necessary to the rest of the paper. Then they didn't have the space to elaborate on the key point of their method, which was reduced to a single sentence. Furthermore, they did not compare their results with the previous algorithm, even though they claimed theirs performed much faster, and handled more complex input.

I wasn't sure if this situation - that is, a paper that contained a good result but that needed some serious revisions in order to present this fact - warranted a rejection or not. I was told that I don't need to be too harsh, given that I was reviewing for a conference, not a journal. So the paper received a 'borderline' grade.

I hope that some of my suggested revisions will be made before the conference, because it would be such a shame to have a mediocre paper when it could have been great. (Or, another way to look at is that I hope that my faith in the quality of conference papers can be sustained by seeing this paper revised before acceptance.)

Friday, January 23, 2009

On Teaching Discrete Mathematics

This semester, I'm TA'ing for a first year discrete mathematics course that covers, among other things, logic, set theory, and graph theory. It's a computer science course cross-listed with math, but many students taking it this semester are actually from engineering. I have to grade assignments and tests, as well as hold office hours, but it's the one hour tutorial I have to lead each week that I want to talk about.

First of all, I want to say that scheduling a math tutorial for first year students at 8:30 on Friday morning is a bad idea. Not just for me, either, because I have to get up early anyway. I still remember how hard it was to get to a 10:00am class after a night of finishing up assignments, let alone 8:30! While there's nothing I can do about how the school's computers make up the schedules, I can try to make the tutorial interesting enough that the students don't start to nod off. More on this later.

This brings me to my second complaint. Last semester, I did tutorials that had 25 people and lasted an hour and a half. This was a great setup since it gave enough time to work on practical things (in this case, on the computers), as well as have some group discussion. There were two TA's in the room, so everyone got a good helping of perosnal attention. This semester, these math tutorials have 50 people in them and last only an hour. This greatly lessens the possibilities of what can be done during the tutorial, leading most people to simply solve problems on the board. A little sleep-inducing so early on a Friday morning, if you ask me.

You have to work with what you've got. We're very fortunate that the professor prepares the questions he'd like covered during the tutorials, giving us TA's a good place to start. My job becomes finding interesting ways to present them. I've only done two tutorials so far, and they were slightly different from each other.

During the first tutorial, I somewhat misestimated how short an hour was (actually, it ends up being only fifty minutes, since five minutes are cut off at the start and end to allow students travel time between classes). I tried to get students to work in pairs on all the questions, after which we shared the answers. While they did get a good feeling for the problems they have to understand, and were able to ask me quesitons, there was almost no time to go through the solutions. They had to look at the answers that were posted online later.

This morning, for the second tutorial, I instead divided the questions and their parts into eight pieces. I then numbered students 1 through 8, thus ensuring they didn't work with who they were sitting beside. (This encourages them to make new friends, but more importantly, it means they are less likely to be distracted by chatting with their current friends.) Since I only had one piece of chalk in the room (argh!), I had them write their answers on the board as they finished. We then discussed whether we thought the answers were correct. Again, there wasn't enough time to go through them all, but we covered much more than the previous week.

So now I need to think of something to do for next week. I like to change it up at least a little bit each week, to keep things unpredictable and interesting. Eventually, this might mean carefully straying from the prepared questions. For example, when they get to graph theory, some CS Unplugged-style activities wouldn't hurt.

If you have any great techniques you've used for math-based courses like this one, I'd love to hear them in the comments!

Tuesday, January 20, 2009

What if Computer Science Had Never Improved?

There's a commercial on the radio around here that asks "What if [some thing or service] had never improved? [Clip of said thing or service not improving.] Here at [their insurance company], we believe insurance can be better."

The most recent edition wonders what music would be like if it hadn't 'improved' since the Baroque period. A man with a rock star British accent yells through the microphone, "Hello Sudbury! Are you ready to.. soNAta?" Harpsichord music follows.

It so happens that I think modern rock concerts are not an improvement over classical music, but it got me thinking about our field of computer science. What if certain areas had never advanced? Are there some areas that are still stuck in the technological stone age?

The first example that jumped into my mind was that of compilers. Imagine what software development would be like if we still had to write our computer programs in assembly code. No fancy objected-oriented paradigms, no interpreted languages, and no simple procedural code! Only the likes of memory addresses and processor instructions. For all but the most ambitious, this sounds like torture. Fewer people would be capable of working in development, fewer large software products would be created, and many other areas of computer science would likely never progress, or do so excrutiatingly slowly.

There's no doubt that computer graphics have come a long way since the early days, growing from text-based terminals to the rich graphical user interfaces of today. If it wasn't for the advances in this field, I believe that computers would never have become accessible to the masses. The ability to display anything the heart desires on a computer screen unlocks so much potential for making interfaces that make sense to everyone, young or old. Modern graphics bring us entertainment, productivity, and everything in between.

The Internet is an obvious example. Remember what web pages looked like in 1995? Plain, non-interactive, and not always entirely useful. Today we are treated to rich, interactive applications, secure online shopping and banking, and about a zillion ways to connect with friends and family from all over the world. Heck, I was even able to watch President Obama's inauguration thanks to the advent of streaming video! The Internet and its related entities permeate our everyday lives so deeply that I'm not sure we remember what it was like to have to see the bank teller, or pay exuberant long-distance fees to contact anyone outside your own town.

What about those areas that haven't broken a lot of ground? I'd like to suggest that artificial intelligence is such an area of computer science. Sure, lots of really great research has come out in the name of AI, but let's go back to the beginning and ask ourselves whether these advances are actually solving the original problem. The field of artificial intelligence was supposed to capture, model, and mimic the intelligence of human beings. This was, still is, and perhaps always will be an impossible task. Many techniques are able to somewhat mimic intelligence levels much lower than our own, or even small particular areas of the way we think, but basically the field seems to have branched away from its original vision. So, in that sense, it never really did progress, though what it has accomplished instead is still wonderful and valuable.

Just like the sonata in Sudbury, some may argue that certain areas of the world of computing may have been better off had they stayed the same. Similarly, maybe the direction AI has taken is indeed a much greater accomplishment that I'm giving it credit for. I suppose that, in the end, it comes down to personal taste and opinion. What I do know for sure is that I can't even imagine where the field is going to be in 100 years, and what commercials we could possibly be making about it then.

Thursday, January 15, 2009

Football's Magic Yellow Line

In the video below (originally seen here), John Gonzalez, a director for the NFL, says that "the greatest thing that's happened to football coverage is the yellow line. I really love watching it and knowing - and not guessing, but knowing - where they have to go to get a first down."

Sports Videos, News, Blogs


This video describes the technology behind the magic yellow line. The most important part of the technique is the ability to determine the orientation of the field relative to the camera. Knowing the perspective of the field allows the line to be placed directly on the surface at the desired position. (Then, of course, it's important to show the line underneath the players, but that's not the part I want to focus on here.)

The cameras used by the NFL are loaded with various sensors that help determine their pose relative to the field. For example, the tilt of the camera can be determined using basic accelerometers. The features of the camera itself, like its current zoom and its physical location in the stadium, can also be used. Once all this data is sent for processing, it can be determined exactly where the field is in the video captured, and therefore where to augment it with the yellow line.

In a sense, this is similar to what I'm trying to achieve with my thesis. In my case, the "football field" is some scene in an urban outdoor area. Let's say it's the National Art Gallery here in Ottawa. The video camera becomes any old camera on a mobile device that a tourist is carrying. Instead of painting yellow lines onto field, I want to be able to augment arbitrary models onto a photograph of the gallery. Maybe I want to add little baby spiders all around the famous Maman sculpture out front.

Unlike the football cameras, though, I don't have the luxury of knowing much about the position of the mobile device. Sure, GPS can get me within a few meters of my 2D position on the ground, but that's not good enough for making a natural augmentation. I need a more accurate position and additional information about how high above the ground the camera is held.

So, instead of using sensors and a priori knowledge, I am trying to match the photos with panoramas that were created with this information. That way, when I know the transformation between the two, I can then project models set up for the panorama into the photo and send the result back to the tourist, just for fun. (I think there are lots of cool applications of being able to augment photos from mobile phones, but I'll save that for another day.)

Monday, January 12, 2009

Let's Talk Science: CS Unplugged and Physics Olympics

I signed up to be a Let's Talk Science volunteer earlier this school year. I'm partnered up with St Mark Catholic High School where I went from grade seven to OAC (i.e. grade thirteen).

My main goal of joining this outreach program was to get students interested in computer science, so I put together a document that summarizes CS Unplugged activities, and suggests what kinds of classes could be connected to the concepts. So far, I haven't received any response from teachers at St Mark, but I think the recent Let's Talk Science newsletter was supposed to mention it. If that doesn't work, I may try contacting schools directly, because I think these activities would be very valuable for students taking computer (and other) classes.

The teacher I'm partnered with at St Mark (along with two other volunteers) teaches grade ten science, which covers topics in chemistry, biology, and physics. Because physics can be kind of dry, the teacher was hoping we could put on an activity to demonstrate concepts of velocity and acceleration. After searching around for ideas of hands-on activities, I found that they were too easy or short for a grade ten class. Instead, I decided to format the activity as a team competition that included questions from the text book and some of the more hands on activities. The result is the Physics Olympics. I'm hoping we will be able to perform this activity soon.

If you think you can use either of these documents, please feel free; just remember to credit me as the source.

Tuesday, January 6, 2009

True Confessions

One of my favourite aspects of blogs like Chick with PhizzleDizzle and FemaleScienceProfessor is their ability to tell their readers so much about what's going on in their lives, thanks to their anonymity. I really appreciate hearing exactly how they feel about their work, research, and colleagues, and details about the challenges they've encountered. Their stories let us know that we aren't alone!

Long ago, I decided to reveal my identity for this blog because I had intended it to be a strictly professional endeavour. I still do. Still, I figured there were a few confessions of my own that I could make, even out here in the open.

Research

One thing I wish I had done more of during my undergrad is research. Looking back, I know that even my fourth year honour's project could have been many times better had I had any previous experience.

It's not like there weren't opportunities, either. NSERC has an Undergraduate Student Research Award that allows undergrads to work with professors over the summer, earning a decent paycheck on the way. I'm pretty sure I had heard about these, but never for a second thought I'd ever be doing research, so didn't look into it. After all, my plans were always to work in industry after I graduated.

Even now, I sometimes wonder whether I'm on par with some of my fellow students. (That could just be a touch of the impostor syndrome kicking in, though.) On the bright side, it's been quite clear how I've improved since starting grad school, which is kind of the whole point I suppose. ;)

Doing Too Much

I guess you could call this one my 'guilty pleasure,' and perhaps attribute my feelings of (slight) research inferiority to it. The truth is that I love to get my hands into many, many things. It makes grad school a much more fulfilling experience. To give you an idea of just how crazy I am, let me list just a few of the things I've been doing just in the last few weeks:
Truth be told, while I certainly don't have as much time to spend on any one of these things, I do tend to get more done when I have some pressure applied. I'm more likely to get up on time rather than sleep in, for example. Still, sometimes I wonder why I put myself through it...

Inkscape

This one actually makes me really sad. I really enjoyed working on Inkscape when I did the Summer of Code, and owe a lot to the folks over there, it being my first (and only) experience with open source development. I continuously thought that I'd be able to work on it 'next semester' but constantly had way too much on my plate to actually do so (see above). Even publicly stating my hope to get back at it failed. Although I can't say when, I really do hope to get back on board and contribute once again.

Moving Away

You might laugh at me for this one. I'm scared of moving away by myself, even for just a semester. I've only moved once in my life, and that was when my fiancé and I bought a place four houses away from my parents. Seriously. So the thought of living by myself to work for, say, Google for a few months is actually pretty much terrifying.

I know it won't be bad once I get there (wherever 'there' is), and I know that it'll be worth it. I'm also not going to let it stop me from taking certain opportunities as they come my way. I'm just going to feel really, really nervous until I actually do it. :)

---

So there you have it. Some of my true confessions. Now you know me just a little bit better. Feel free to comment and tell me about yours.

Monday, January 5, 2009

All girls for non-photorealistic rendering?

Although I don't technically need the credit, I'm taking a class I thought looked interesting. It's about non-photorealistic rendering, and should include a lot of topics that are useful for my thesis, including more image processing, computational geometry, and so on.

Now, I don't know if women are more interested in visual topics or what, but when I walked into the first class this morning, I was shocked to find that, other than the professor, the room contained only females!

Ok, before you get too excited, there were only two students other than me. And a boy walked in five minutes after I did. But it was still cool while it lasted.