Matt's Blog

Nearing the End

2010-08-07T11:52:00.000-07:00

Well there's only a week left in GSoC, and plenty of coding left to do. We're supposed to focus on bug fixing and documentation only next week.

It is definitely true that my project became more and more of a bear conceptually as I continued on. Right now we are subclassing sympy's Mul, Add, and Pow classes in order to circumvent any sort of non-commutative/validation/operator problems. We've definitely found a way to avoid most/all of the design issues that I was faced with a few weeks back. Overall, I think a very respectable version of symbolic quantum mechanics (with a quantum computing example) will be ready by the end.

This last week, we made a lot of progress on QMul, QAdd and QPow. I mainly observed that as we added more and more degrees of freedom (more code), more bugs and weird errors arose. I helped fix a few of these bugs including one today in which Bra('a')*Operator('b') was returning only Bra('a'). The fix was really simple (changing one line), but finding it was much more difficult. It was a good experience because I used more advance forms of debugging that I had previously not needed before.

Next week I'll write some tests and debug more. Things will start winding down and my project will be done soon enough :)

More Design Issues

2010-07-31T11:14:00.000-07:00

Unfortunately, it seems with my project that we keep running into more and more design issues. Put simply, the issues arise with Sympy's Mul and Add (and Pow) classes. In order for my quantum objects to be handled properly, we are going to have to subclass these classes. You can find more information about the issues here (originally posted on the Sympy Google group).

With all that to say, there still is a bit of time for coding left! Next week, we are going to subclass Mul, Add, and Pow (qmul, qadd, qpow). After that happens, I plan on creating a physics example that uses the existing quantum library I've helped build. I think I'm going to do the particle in a box (with infinitely strong walls) and use a position state to do so.

More on this next week when we get everything sorted out!

More Improvements and Nice Printing

2010-07-24T14:07:00.000-07:00

This week was quite spread out in terms of what I coded in quantum.py. I made inner products work with operators and other objects in between them. We made pretty print work with various quantum classes. And finally I made a suite of validating/combining/separating functions for inner and outer products.

First of all, let's look at how pretty makes quantum objects very readable. Let's create the iconic psi state (ket):

In [5]: psi = Ket('psi')

In [6]: psi
Out[6]: |ψ>

Next let's create an operator and dagger it (and leave it unevaluated):

In [9]: a = Operator('A')

In [10]: Dagger(a)
Out[10]:
†
A

(the dagger symbol normally appears as a superscript to A, but Blogger is temperamental)

Inner products can have objects (mainly operators) between them now. Outer products will not have this functionality because it is not valid for them. When someone creates an inner product, they must instantiate the class because states and operators (and such) cannot automatically combine with their __mul__ method due to a very tricky reason (the subtlety lies deep within sympy's Mul class):

In [12]: bra = Bra('_a')

In [13]: b = Operator('B')

In [15]: ip = InnerProduct(bra, b, a, psi)

In [16]: ip

Out[16]: <_a|⋅b⋅a⋅|ψ>

In [17]: ip.bra

Out[17]: <_a|

In [19]: ip.ket

Out[19]: (B, A, |ψ>)

Now let's take a look at some of the special functions I made:

In [23]: expr = bra*a*b*a*psi*a

In [24]: expr

Out[24]: <_a|⋅a⋅b⋅a⋅|ψ>⋅A

In [25]: srepr(expr)

Out[25]:

Mul(Bra(Symbol('_a')), Operator(Symbol('A')), Operator(Symbol('B')), Operator(S

ymbol('A')), Ket(Symbol('psi')), Operator(Symbol('A')))

(let's see if this is a valid mul by using the validate_mul function)

In [27]: validate_mul(expr)

Exception: Ket*(Operator or OuterProduct) is invalid in quantum mechanics.

=============================================

(so now let's make a valid expression)

In [28]: expr = bra*a*b*a*psi*bra*a*psi

In [29]: inprod = combine_innerproduct(expr)

In [30]: inprod

Out[30]: <_a|⋅a⋅b⋅a⋅|ψ>⋅<_a|⋅a⋅|ψ>

(these functions automatically check to see if the mul is valid with validate_mul)

In [31]: srepr(inprod)

Out[31]:

Mul(InnerProduct(Bra(Symbol('_a')), Operator(Symbol('A')), Operator(Symbol('B')

), Operator(Symbol('A')), Ket(Symbol('psi'))), InnerProduct(Bra(Symbol('_a')),

Operator(Symbol('A')), Ket(Symbol('psi'))))

=============================================

In [32]: outprod = combine_outerproduct(expr)

In [34]: srepr(outprod)

Out[34]:

Mul(Bra(Symbol('_a')), Operator(Symbol('A')), Operator(Symbol('B')), Operator(S

ymbol('A')), OuterProduct(Ket(Symbol('psi')),Bra(Symbol('_a'))), Operator(Symbo

l('A')), Ket(Symbol('psi')))

=============================================

(you can also split the products; I'll show you how this works on the inprod expression)

In [36]: split = split_product(inprod)

In [37]: srepr(split)

Out[37]:

Mul(Bra(Symbol('_a')), Operator(Symbol('A')), Operator(Symbol('B')), Operator(S

ymbol('A')), Ket(Symbol('psi')), Bra(Symbol('_a')), Operator(Symbol('A')), Ket(

Symbol('psi')))

(see, no more inner products!)

=============================================

So we see that the same expression can be combined into inner products or an outer product depending on which function one uses. And we can also split up the inner or outer products.

In the last few weeks of my project, we have decided that it would be best if I started working on applications with this code such as an infinite square well and other quantum physics examples. We'll see initially how far I get on this next week!

An Enjoyable Week

2010-07-16T18:43:00.000-07:00

This was a good week. I coded some stuff that wasn't nearly as abstract as Hilbert spaces, and my midterm was completed.

Overall, I would say that I'm quite satisfied with my progress. We are still working on the many products between quantum objects, but that doesn't mean I can't work on the objects themselves or functions. As we saw in my previous post, basic symbolic quantum mechanics is coming together and it is very nice to see so.

It seems that when we try and implement products between these objects (inner and outer products included too now unfortunately), many difficulties arise in the design decisions. That's okay though, sometimes things just catch us off guard sometimes. I know that in a few weeks everything will be nicely glued together (in a tensor product sense).

Midweek Madness: Quantum Physics Examples

2010-07-14T16:42:00.000-07:00

The code is starting to get quite amusing (especially because of how intuitive it is to implement something in Sympy). I have made basic quantum states (bras and kets) functional for now sans any sort of tensor products (postponed for the moment). There are other kinds of products though that need attention too like inner products and outer products, and they are now implemented in my code. I'll give more details on my overall progress when the week ends, but for now let's look at some physics/code in action (using the wondrous iPython shell running quantum.py and hilbert.py):

Make bra and ket states:

In [3]: a = Bra('_a')

(I have to put the underscore because html starts getting in the way with the less-than sign.)

In [4]: b = Ket('_b')

In [5]: a
Out[5]: <_a|

In [6]: b
Out[6]: |_b>

Now let's create a Hilbert space for them to live in:

In [7]: state_space = l2(2)

In [8]: state_space
Out[8]: l2(2)

In [9]: a.hilbert_space = state_space

In [10]: b.hilbert_space = state_space

(This process could change slightly in the near future.)

We can check to see if they live in that Hilbert space!

In [11]: (a and b) in l2(2)
Out[11]: True

And now let's do some inner and outer products:

In [12]: a*b
Out[12]: <_a|_b>

In [13]: type(a*b)
Out[13]: <_class 'sympy.physics.quantum.InnerProduct'>

In [14]: b*a
Out[14]: |_b><_a|

In [15]: type(b*a)
Out[15]: <_class 'sympy.physics.quantum.OuterProduct'>

You can also "Dagger" (complex conjugate transpose) stuff:

In [16]: Dagger(a)
Out[16]: |_a>

(a was a bra, now it's a ket)

In [17]: Dagger(b)
Out[17]: <_b|

(b was a ket, now it's a bra)

In [18]: Dagger(a*b)
Out[18]: <_b|_a>

In [19]: Dagger(b*a)
Out[19]: |_a><_b|

(inner/outer products reversed)

Right now I've only shown pure symbolic calculations, but functions such as Dagger can also be used numerically (also this is a symbolic project!).

Design Decisions

2010-07-09T09:37:00.000-07:00

This week I was faced with difficult design decisions. Originally, we had thought everything would go smoothly when I switched from Hilbert spaces to operators, states, etc. But in practice we encountered very deep, fundamental design issues with inheritance and structure.

The issues arise with how we are going to handle tensor products, direct sums, and tensor powers (I will refer to these as simply the "operation base classes") between quantum objects. In order to explain the issues better, I will outline the four (current) possibilities we have come up with for the quantum structure of sympy:

1) Operation base classes function like Mul - nothing inherits from them:

Cons:

Operation base classes cannot have any special methods or attributes tied to a quantum object.
These classes then cannot act like a macro version of what they contain.

2) The following multiple (diamond) inheritance tree:

Where "something" means an operator, state, etc. and "Tensor Product" is just a placeholder for any operation base class (which of course includes tensor products). Dr. Granger posted questions on this (and similar structures) to the sympy group, and it was recommended that we inherit from Basic instead of Expr, so the top of the tree could change. The only con with this approach is how exactly the inheritance works (subtlety lies in __new__).

3) Create tons of subclasses (brute force style), where a bunch of TensorProductSomethings exist and no generic TensorProduct exists.

Cons:

code repetition (completely defeats the purpose of object oriented programming)!

4) Possibility 2+3 hybrid:

Where operation base classes do not inherit from Expr (or Basic) - they only contain common logic that all TensorProductSomethings use.

So it's kind of complicated. But we'll sort through everything (including all the generous feedback) and come up with a solution so that I can get on with coding!

Interesting Times

2010-07-03T15:33:00.000-07:00

So this week I submitted my Hilbert space code for review on the sympy patches group.

It went well. There were plenty of comments/concerns. I answered them all and made sure the code passed all of the tests. One of the issues at first was the code quality test not passing (whitespace errors, implicit import, etc.). I interpreted this wrongly at first and thought it didn't apply to my code (for whatever reason). But now it's all fixed!

Some more crucial changes included adding more tests to see if things do/don't commute. Also, I needed to update the direct sum class and make sure it commuted :p

Overall, I can see why review processes take place - you get to see if your code isn't completely ridiculous :)

On Friday I also dabbled in multiple inheritance with the __new__ method. It's going to be interesting creating a direct product/sum ancestor class for everything to inherit from as well as mul and add. We shall see next week when I enter deeper (quantum) waters.

Week of Code Part 2: Examples and Physics

2010-06-26T16:22:00.000-07:00

So it's finally time for me to start showing off my code to the rest of the world. I'll start with a simple example on how to create a Hilbert space. In these lines of code, I create an l2(2) Hilbert space (2 dimensional):

        >>> from sympy.physics.hilbert import *
        >>> hs = l2(2)
        >>> hs
        l2(2)

As we see, SymPy is able to know what an "l2(2)" is, and it can print it back out to us. By the way, this is the kind of Hilbert space that qbits live in!

Let's move on to a more complicated example where my code combines tensor products (analogous to multiplication for Hilbert spaces) into a single direct power (repeated tensor products):

        >>> ms = hs*hs*hs
        >>> ms
        l2(2)**(3)

The variable "hs" is the same as in the previous example. And what do you know, they combined into a single direct power object which is seen printed in the last line! The code is really smart when it comes to combining these powers, so it can deal with more complicated examples such as combining powers with symbols in them. It also knows that tensor products are non-commutative, so it will not simply find all identical Hilbert spaces and combine them (only if they're "right next to each other"):

        >>> from sympy.physics.hilbert import *
        >>> from sympy.abc import x
        >>> hs = l2(2)
        >>> direct_power = hs*hs*(hs**2)*(hs**x)*hs
        >>> direct_power
        l2(2)**(5 + x)

See how "direct_power" has an assortment of identical Hilbert spaces each with a different direct power. It knows to combine them into a single direct power!

I was very satisfied when I got this working, and it has definitely caused me to be addicted to coding (especially when something isn't working)! Until next week :)

Week of Code Part 1: The Summary

2010-06-26T01:15:00.000-07:00

Now my GSoC experience is purely coding - as it inevitably should be! This week was spent entirely on finishing the Hilbert spaces basis in SymPy.

Last week, I started a huge test file for hilbert.py and finished it this week (mainly adding direct power tests). I definitely know that later on in the summer when I'm working on other direct products and sums, I will need to perhaps add a few more methods and properties to hilbert.py and its test file, but for now they are very solid.

I would say the most difficult part of my week was teaching my code to intelligently handle the combining of tensor products into direct powers. I definitely think this was a good lesson in logic and coding; it really helped iron out any kinks I had with programming in general. I'll post an example of how it combines powers tomorrow in the second part.

It was a difficult week - more difficult than any of the others. It was definitely the most rewarding though! I feel much more solid with coding in general. More on everything tomorrow including examples and physics in Part 2!

Coding and Other Festivities Begin

2010-06-18T21:56:00.000-07:00

The summer has officially started, and GSoC has my full attention.

I started this week off by reading a hulking amount of material on Python and quantum physics. We're talking hours and hours of reading - time consuming but rewarding. I picked up a few new object methods here and there in the Python book, and I learned about dictionaries, an object I previously had no knowledge of. As for the quantum physics, I read the appendix (pure linear algebra) of my quantum book from PHYS 405. I also read excerpts from Dr. Granger's grad school level quantum book. Lots and lots of reading...

But I did do some code interpreting (more reading; different kind) and coding! I started by creating my own sympy fork on github and creating a quantum branch with Dr. Granger's quantum files patched in and pushed. I concentrated mainly on the hilbert.py file, as implementing Hilbert spaces is my current task in my GSoC proposal. I needed to look over everything and understand what it is trying to do and what it is inheriting from to do it. And everything works remarkably well right now. There are a few design issues I think I need to work out with the inheriting (e.g. direct products and sums need their own class that the Hilbert ones will inherit from), but overall everything is pretty well laid out.

I started the test file: test_hilbert.py (found in the tests directory of my physics directory here). I've never written a test file before, so this was good practice. I may have gone overboard on the tests, but this was a good experience not only for the sake of writing tests but also to find some dimensionality issues with direct products and sums in hilbert.py. Infinity times a number is infinity, right? Well, due to some subtle simplification errors with symbols and infinity (oo in sympy) there is a problem with calling the dimension of a direct product or sum. I'll fix this next week, I promise!!!

Anyway, I had a grand old time this week, and highly uncannily my PHYS 405 professor, Dr. Gutierrez stopped by and talked about a bunch of crazy stuff that nearly blew my mind (or something like that).

Out of The Fire; Into the... Tropical Ocean of Code and Quantum Physics!

2010-06-11T22:57:00.000-07:00

So my finals week has finished, and I have to admit that my mind is slightly expired. I'll use this weekend as a relaxing transition from school/research/light-coding into more full time coding and fascinating quantum physics lectures from Dr. Granger. Next week, full speed ahead!

I'm also probably going to pick up a couple of excellent books relevant to topics I'll be dealing with this summer: Python and Quantum Computing. The two books are "Quantum Computer Science" (Mermin) and "Python for Software Design" (Downey). We actually have the two books in our computer lab on campus, and I took a look at the quantum computing one. It had very interesting topics discussed in it including entanglement - my personal favorite.

Also, in my last post I touched on Hilbert spaces (L2 & l2). I was talking to my friend (math major) today and he told me that there are Lp spaces (L2 & l2 are just the beginning). He told me about the norm in those spaces and other interesting properties. It was kind of humbling to learn that the space I'm working in these next few weeks is just a part of a more general set (there seems to always be a bigger fish no matter what space or dimension or whatever you look at)!

Ahead On Our Way

2010-06-04T19:27:00.000-07:00

This week in GSoC our gang decided to concentrate primarily on quantum physics, namely Hilbert spaces.

Dr. Granger lectured on the basics of what a Hilbert space demands from a vector space (a Hilbert space is a subset of a vector space). The main requirement is that the inner product between to vectors is defined. The vectors may be continuous (functions; L2 Hilbert space) or countably infinite (discrete component; l2 Hilbert space). The direct product is the "multiplication" that is defined for multiplying two Hilbert spaces. We observed that __mul__ in Sympy will need to be overwritten in order to properly interpret multiplying vectors in their respective Hilbert spaces.

As for Python, we began looking at decorators. More on this to come (when I'm not buried in huge HW assignments, lab write ups, projects, and finals)!

Getting Started

2010-05-28T21:10:00.000-07:00

GSoC began last Monday (5/24/2010) :)

I'm in the "Investigation" period of my project, where I research and learn quantum mechanics at Cal Poly. Right now we are taking the formal approach towards quantum mechanics in class. We have learned about states, bras, kets, and operators (not the phone kind). I'm finding this all quiet interesting, and I often think of the place this math has in the coding context during lecture.

Also, Addison and I are playing around with a very simple version of a symbolic math "library" for python that we coded and published to github (http://github.com/mattcurry/scratch). We started with our intuitions on how a symbolic math library could function, and then we encountered some of the design decisions that sympy had to face when it was first being created. Dr. Granger helps us a lot with making the code function more like sympy. I think this is a great way to understand sympy on a deep level. After all, I need to know what my classes are inheriting from to some degree before I start coding during the summer.

I'm definitely enjoying it all so far, so I know I'm doing the right thing!

PROPOSAL ACCEPTED!!!!!

2010-04-27T13:13:00.001-07:00

An amazing day it was, yesterday.

SymPy Patch

2010-04-15T10:27:00.000-07:00

I've patched SymPy for the first time! I fixed a string name conflict with the various printmethods SymPy uses (the conflict happened between SymPy and Sage). I submitted my patch here. Also, I used git to clone the SymPy repository and create the patch file.

Proposal In

2010-04-12T19:55:00.000-07:00

Last Friday I submitted my proposal to Google Summer of Code's website. You can take a look at the proposal here: http://docs.google.com/View?id=dhd962vk_84p6wjkfc. I'll know if my proposal gets accepted on 4/26/10!

Welcome

2010-04-05T20:56:00.000-07:00

Welcome, myself, to the world of blogging.