Friday, July 30, 2010

Integration of General Quantum

This week, I started to integrate Matt Curry's general quantum stuff into my code; this was done both to prevent replication of code in our two modules and to test to see if his code worked in a practical problem.

That said, I spent quite a bit of time this week inside Matt's code. Dr. Granger and I ported my represent function into Matt's code so that we could represent not just Qbit systems, but also other systems by specifying a BasisSet and how to represent an individual State or Operator in the Basis. Matt and I worked together on developing validate functions that use the new op.priority feature to check to see if Quantum expressions are valid; testing this is still ongoing and has serious limitations because Sympy's AssocOp classes cannot know the special rules that go along with its args. This leads to issues that are hard such as how to call our validate functions automatically when all quantum objects are held within a Sympy binary-operation (e.g. Mul(Operator, |Ket>) + Mul(Operator, |Ket>).

While helping Matt get his code up and working, I was also busy inheriting and porting features from Matt's code. This was a pain as little changes caused large errors throughout my code; I especially had a hard time dealing with the ket attribute inside State since Sympy keeps all attributes inside an args list rather than an ensemble of separate attributes with their own names. This ultimately meant that I had to rewrite how I parsed the args for Qbit, making args[0] be a tuple which contained the real attributes and args[1] be information about it being a ket.

As I continue to play with Matt's code, I get a better idea of the serious design problems he is running into. These issues have apparently been run into before with Matrices (The issues with Matrices are very similar in that they have special rules for what can be multiplied and need to maintain these rules even when held inside a Mul object). The Matrix class got around this by standing alone, not inheriting from Expr, and rewriting its own __mul__ method; this meant that, since Expr's don't know how to multiply by Matricies, Python would default to the Matrix's __(r)mul__ method. This is quite kludge-y, I should hope we come up with a better solution than this. The addition of op-priority is a good start to the fix, but will only fully work if the Mul object itself knows how to use this feature.

I need to clean up both my and Matt's code in the following weeks as I would like to have a good product by the end of GSoC.

1 comment:

  1. It would be great if you could come up with a good way to do this so it can be applied to Matrix.

    ReplyDelete