GSoC 2010 Symbolic QMReport

About Me

I’m Matt Curry and I will be entering my senior year as a physics major at California Polytechnic State University (Cal Poly), San Luis Obispo, CA. My primary fields of interest (for research and otherwise) are quantum physics and quantum information science.

Introduction

I had a great summer working on a project that I was genuinely interested in. The goal of my project was to have a complete base layer set up for implementing symbolic quantum mechanics in SymPy. In the following sections I will explain the successes I had as well as the difficulties I faced while coding my Google Summer of Code 2010 project.

Application Process

It is tempting to say that the most difficult part of Google Summer of Code (GSoC) is the application process itself. This process occurs alongside classes and can be quite time consuming depending on when the application is started. I started about a week and a half before the deadline and the combination of writing up the formal proposal and completing my various lab write-ups, quantum mechanics problems and other physics homework left me with little to no free time. After I finished the proposal there was peace for a time (albeit catching up in classes was necessary). And it was definitely relieving to find out that my hard work had paid off, as my proposal was accepted by Python Software Foundation.

GSoC Project

Since my mentor, Dr. Granger, is a professor at Cal Poly, I have always had top notch communication with him. We decided it would be best for me to get familiar with coding in SymPy by helping create a small-scale version of SymPy with only the absolute core functionality. This was a very wise task for me because it not only taught me about how SymPy works, I was also able to wrap up some loose ends I had with Python and object oriented programming in general.

When GSoC officially started, I was still going to school (for three more weeks). I anticipated this in my proposal by giving myself the time for researching Python and quantum physics. I did most of my Python research online as well as creating the dummy SymPy module. My quantum physics research was taken care of by my enrollment in a quantum physics class at Cal Poly. During finals week I allocated most of my time to my studies and mentally prepared for the coming week (the beginning proper for my project).

Much to my surprise the first week of my project was spent mostly reading full time. I read a book about Python and several books about quantum physics. I did code a tiny bit toward the end of the week, but that week was quite a book week. The following week I finished up the Hilbert space module started by my mentor. This was quite intuitive coding because all key design decisions had been made, and I only had to write tensor powers and add some recursion (along with many other tiny code additions). I had a lot of enjoyment at the end of the week understanding the whole module and seeing it work in the iSymPy console. After I was done writing everything including a test module, I submitted my code to the SymPy patches group for review. The review went well, and I addressed all issues raised by the SymPy community.

The next phase of the project was to create the complete structure for symbolic quantum mechanics (i.e. states, bras, kets, inner products, etc.). Before jumping into coding, I needed a design for tensor products, direct sums and tensor powers (some extra operations in quantum mechanics). My mentor helped brainstorm some possibilities outlined here in my blog. Each possibility had benefits and consequences, and we didn’t want to create a structure that would have to be completely reworked later on. After some careful thought, we decided to postpone this portion of the quantum base layer and move onto to the quantum objects themselves (which through SymPy’s Expr/Basic classes have standard operations defined between them i.e. multiplication, addition, etc.).

I began coding quantum objects and testing their interactions to see if everything was working. This was one of the most enjoyable parts of my project. I loved seeing a bra and a ket being multiplied and combined into an inner product (even though we changed this behavior later). Coding was going well for the next few weeks, and I made some test files and expanded the functionality of this quantum base layer. Our next big design issue that we faced dealt with SymPy’s handling of operations and Expr objects. Using the new method in SymPy to create an Expr object was always wonderful until this point; it had made coding far more trivial and allowed the user to focus on his object’s basic behavior with simple math already taken care of.

I’ll illustrate problem that we faced. Say I wanted a special rule with my code where I don’t want to allow multiplication of an operator and a bra (OperatorBra). If I type that directly into iSymPy, everything will be fine because either quantum object’s custom mul method will be called (and presumably check for this incorrect multiplication). Now say I multiply two operators as such: “op = OperatorOperator” The “op” object is now SymPy’s Mul object (no longer an Operator object even though it contains Operator objects!). If we multiply opBra, op’s mul method will be called and it is simply Mul’s mul method (suspiciously sounding like some demented alliteration). Now I couldn’t code in special rules unless I changed Mul’s mul (not an option). This problem was taken care of by having SymPy implement operation priorities (essentially the Bra’s rmul method will be called which can have special rules in it). But ultimately we couldn’t escape problems such as two Mul objects multiplied together with quantum objects in them (MulMul, where it doesn’t matter which Mul has priority – it’s still a Mul).

So for the remainder of my GSoC project, I helped create custom Mul, Add, and Pow (QMul, QAdd, and QPow) classes. This ended up finally being a workable solution even though it unfortunately involved us not using some of SymPy’s core code. We found out that Matrices in SymPy faced similar problems and hopefully one day they can use our code.

Conclusion

Even though I faced quite a few deep design challenges this summer, I benefited greatly from the experience as a whole. I’m much better at programming after completing this project, and I learned so much more about computer science in general. Quantum mechanics takes a while for a physicist to build an intuition for, and the huge amount of research and reading that this project required/inspired me to do is invaluable. Ultimately, I now have a solid confirmation for what I’m genuinely interested in.

Future Work

Although GSoC 2010 has ended, my work with quantum mechanics in SymPy will continue this year for my senior project at Cal Poly. I will probably be working on the extra operations and some neat physics examples (the particle in a box example has already begun). I’m excited for the coming year and hope for the best with this alongside grad school apps :)

I would like to thank my mentor, Dr. Brian Granger, for all the help that he gave me over the summer. And thank you, SymPy community, for your comments and help!