Quantum Oscillator

February 6th, 2010

Every Friday evening the graduate students at SFU have a problem solving session where we try to solve a problem as a group that one of the faculty proposed. This week we were asked to numerically compute the solution to the quantum oscillator. The solution to the problem is really neat and it is something that you don’t usually get to see. Most physics programs don’t bother to show you how the quantum oscillator moves.

For those of you that care, we were solving the following equation:

 i \epsilon u_t + \epsilon^2 u_{xx} = (x^2) u

with periodic boundary conditions, and an off-centered Gaussian as the initial conditions. We ended up using a spectral method to solve the problem using python. You can check out the code here.

How do you deal with programmers who are intellectually bored at work?

February 5th, 2010

I finally had the guts to ask a question on the Stackoverflow Podcast. My question was…

Hello Joel and Jeff,

My name is Jeffrey Wiens and I have been a developer for around 4 years. I am currently in a applied mathematics graduate program because I needed something more challenging than what my previous jobs could offer.

As a manager, how would you deal with programmers like me that are intellectually bored at work? And how do you balance this with your company’s immediate needs which may be intellectually unrewarding?

I think Joel and Jeff kinda missed the point. Well at least Joel missed my point (I think). Either way, you should still listen to the podcast. Instead of answering what managers should do with bored programmers, they answered what I (or bored programmers) should be doing. To summarize their response, they thought that boredom has more to do with your metal state instead of the task at hand (which I totally agree with). Also, that any programming project can be interesting if you are working at the correct level of abstraction (which I tentatively agree with).

I totally get that your metal state has more to do with boredom than with the task at hand. For any task, I bet that you can find at least one person that finds it interesting. However, I wouldn’t say that every person could find any task interesting. Now, in a previous life, I used to be a contractor for Powerschool. This company sells software that manages general student information (ie. grades, attendance, etc) for public schools. In order to get funding, every school in the US needs to submit a set of reports to the government. One of the benefits of using Powerschool is that they create these reports for you. My job was to create some of these reports. The annoying thing about these reports is that they varied from state to state. The work was really not interesting. It involved reading a lot of government documentation and writing simple programs in a domain specific language. When it came to programming, all we needed to do was grab fields from the database, do some minor calculations, and then dump the data to text. To make things worse the domain specific language was horrific. If I had the power, I would have created an environment to address these issues using a more standard technology. However, the decision was not for me to make. For some of the programmers, the job was satisfying. However, it was not satisfying to me. Reading government documentation was boring and there was no inherit difficulties in the problems we were solving. The best choice for me was to obviously leave. However, when I left, I took a year’s worth of knowledge with me. Personally, I don’t really care. I took the job because I needed experience and I was tied to a certain location. However, as soon as I had another opportunity, I took it. But this leads to my original question about managing bored programmers. How could have Powerschool have kept me? If they had no desire to keep me, that is also fine. I am far happier because of it. However, what if Powerschool did want to keep me? What could have they have done?

This was the point of my question. I personally don’t care if your company hires me or not. Likewise, I don’t care if your company is intellectually engaging or not. However, my life is way to short and precious to waste it. If I am not enjoying my work, why should I stay? However, the problem is that managers should care that I stay. When programmers leave, they take the knowledge with them. This is a big problem.

I think that part of the answer to my question can be found in my next job at Trinity Western University. The university had an in house development team which created custom solutions for the university. The job could have been just as boring as my last one. However, the manager and team made it an awesome place to work. It is by far the best place I have ever worked. The thing that continues to surprise me is how they managed to hire so many high quality developers. I think the answer lies on how they handled intellectual boredom. The first thing that they did well was that they allowed you to experiment. Instead of taking the easiest/simplest route, they allowed you to try new things. These experiments didn’t always turn out. However, some of them did and offered huge improvements to the old system. As a manager, it is very tempting to take the cheapest and easiest solution. However, if you want good developers, you won’t get them by doing this. The second thing that Trinity did was create Professional Development Days. I learned a lot of stuff through them. For example, one friday I created a spam filter for our support system. Did we really need a spam filter? Not Really. However, I learnt a lot about Machine Learning because of it. The great thing about Professional Development Days from a managers perspective is that these side-projects often snowball into larger personal projects. This is knowledge that could help your company.

Anyways, despite all the positive attributes of Trinity, I still decided to go back to school. As much as I loved working there, I still couldn’t see myself working for them in ten years. Either way, I was hoping that Jeff and Joel would shed some light into my question. Perhaps boredom is just a personal problem. However, some companies seem to be less boring than others. I thought Joel would have some insight on what companies could do to make the job more interesting.

The Dark Side of Perl

January 16th, 2010

Code! Yes. A programmer’s strength flows from code maintainability.
But beware of Perl. Terse syntax… more than one way to do it…
default variables. The dark side of code maintainability are they.
Easily they flow, quick to join you when code you write. If once
you start down the dark path, forever will it dominate your destiny,
consume you it will.

- Yoda [1]

[1] http://www.netfunny.com/rhf/jokes/99/Nov/perl.html

Simulating when a Green Light turns Red

January 9th, 2010

In a previous post, I talked about the Stochastic Traffic Cellular Automaton. I am finally going to post some simulations of this method. If you want to see the code, please leave a comment.

In this simulation, I will be modeling the traffic flow of an intersection when a green light turns red. From personal experience, you know that traffic will slowly get backed-up behind the red light. This can be described as a shock wave.

In Chapter 5 in Mark Holmes book “Introduction to the Foundations of Applied Mathematics”, he sets-up the exact same problem. If you want more details on the problem, you can download the chapter for free on his website.

In my simulation, I have discretized the road into 1000 segments and evenly distribute 250 cars as the initial data. I then set the max speed M to 2 and the probability to slow-down p to .25.

The following picture shows you how the simulation ran. Each row (left to right) represents the entire road where the black spots represent cars. As you move down, you will see how the road changed for each time-step. It might take you some time to make sense of the picture.

As you can see, the traffic on the right hand side starts to pile-up more and more as time goes on. This can be easily seen by the following movie.

The top plot shows the simulation for the Stochastic Traffic Cellular Automaton model. The plot below it shows the exact solution to the continuous Lighthill-Whitham PDE Model which I described in my poster presentation. As you can see, the two models behave very similarly.

Lastly, I ran the simulation 10,000 times. After running the simulations, I calculated the probability that a car exists in a particular road segment. This created a traffic density curve similar to the Lighthill-Whitham model which is shown in the following video.

Changing PDF Metadata on Ubuntu

January 4th, 2010

I got a Sony E-Reader as a Christmas present from my parents this year. I absolutely love it! It will definitely change how I read books. I no longer have to lug around several books everywhere I go. The best part is that I can put all my journal articles in it. I no longer have to print off hundreds of pages of journal articles. However, there is one thing that I have found really annoying. It is practically impossible to find programs that change the pdf’s metadata. It took me awhile to find one that actually worked.

I ended up finding a Linux Program called PDFTK. I wanted to go over some basic commands (mainly so that I can find them easily).

Installing PDFTK:

sudo apt-get install pdftk

Edit Existing Meta-Data:

pdftk book.pdf dump_data output report.txt

You can then edit the data in report.txt which we can later upload back to the pdf. The text file will contain key value pairs like:

InfoKey: Title
InfoValue: Coders At Work
InfoKey: Author
InfoValue: Peter Seivel
InfoKey: Subject
InfoValue: Programming

After you edit this file, you can update the new meta-data to the pdf.

Update PDF Meta-Data:

pdftk book.pdf update_info report.txt output bookcopy.pdf