..where we discuss density operators wrt SymPy

Week 5 : Tr class implementation

I had not blogged during last week since I was away at the summer school where I had an opportunity to listen to and talk to both physicists and cs theorists working on the next quantum computer! There were  great presentations and the videos should be available shortly. So, now back to Sympy!

Tasks accomplished this week

My main tasks for this week was to address all comments on pending PR 1333. In addition I had planned to complete printing operations on Tr operator and get started with qubit related Tr operations.  I accomplished the task on addressing comments on PR 1333 and also completed basic printing operations along with having the notebook examples done.  The changes outside of PR 1333 are available in my githhub branch(trace_permute_equal) and I plan to submit a PR for these changes as soon as PR 1333 is merged.

In addition I worked on providing a permute() function and also had to play around with implementation of overriding _hashable_contents() method.  I had spend some time in figuring out the details of such an implementation and there was some discussion on this on the mailing list.  For now, I have these 2 functions implemented ( but commented out) in branch trace_permute_equal.

Therefore, one task that remained but which I could not get to this week was qubit implementation related to Tr.  Also, currently I am in the process of writing up how Tr operations should work on TensorProducts. I should have a write up very soon.

The tasks for next week, therefore would be  (roughly in this order)

1. Share a write up on TensorProduct wrt to Tr operations.

2. Push qubit related changes to my git repo

3. Get started on TensorProduct/Tr and have the first cut ready for review.

4 Get PR 1333 merged.

5. Get branch trace_permute_equal merged. This branch has minor changes and I hope to get this merged as well this week.

Happy coding!

Week 3: Activity Summary

My week started with some design discussion with my mentors @ellisonbg and @flacjacket.  We had a preliminary discussion on how we should go about implementing the Tr (trace) operator.

Based on the preliminary discussion, I submitted a PR 1333 purely for review and got some useful comments. I went back to work and addressed almost all the comments/suggested provided and I have updated the PR with my new changes.

As it stands now, the current PR 1333 has the basic functionality needed for Tr operation. This version still does not handle reduced trace operations and also does not use any options passed through **kwargs.  Even, printing will have to be fixed. But, barring any major issues after few more iterations the coming week I am confident this PR can be merged.

So, assuming I will not be adding any more features to the PR, my plan for next week is make sure this PR gets accepted.  Since, I am at the summer school next week, I may not be doing any other new coding activity. So, my minimal goal is to make sure this PR is merged by end of next week.

I plan to branch out of this PR, to work on the following activities during next 2 weeks(mostly week after):

1. Fix printing for Tr operator. Currently, the printing is pretty crude. I will also add examples for Notebook along with this task.

2. Fix the is_number operation ( based on what suggestions I get). I am still to understand what “is_number” means to sympy and what scenarios Tr needs to handle.  I need to work on this property, since this property is called from the base classes for when 2 Tr objects are added through Add(*[Tr(args,indices)]) operation.

3. Integrate currently existing Qubit logic for partial trace operation.

The above 3 tasks should go into the next PR.

4. Meanwhile, I would like to chat with my mentors and about all use cases (general/special) that we will have to address to TensorProducts wrt to density operators and eventually partial trace operations.

Edit 1: Update (1) to include Notebook.

Week 2: Activity Summary

This week there was fewer lines of code than last week. But, with this week I have almost(except partial trace) merged all changes from @ellisonbg’s densityop branch and ready to extend the implementation to incorporate other features.  Most of the time I spent this week is to review and structure my work for the coming weeks and address comments on previous PR . I have provided a detailed plan below.

Tasks performed this week

1.  Responded to and completed all comments on last weeks pull PR1312.
2.  Pushed a minor code change branch to my git account. This change handles entropy for general density operators.  (I am still waiting for the previous pull request to get merged, since this pull request was branched off that.)
3.  Review and understand the partial trace operations and qubit related implementation.  Further notes will be prepared for the discussion.
4. Understand current implementation of tensor products to plan work for coming weeks.

My plan for weeks 3,4,5,6 ( based on design discussion we have had regarding partial trace )

(Note, the detailed plan here still meets the timeline outlined in the proposal. The only change is I will be working fewer hours during Week 4(June 10-16), since I am at the summer school. Hopefully, I can contain the work to not flow into later weeks). 

Week 3/4

Implement/test partial trace methods [ _eval_partial_trace ] and other required methods for following classes:

QubitDensity (name suggestion needed!) : for this I will use the current bit-twiddling algorithm but add detailed test cases.
TensorProduct : Code to handle density operators ( both qubit based, and generic) during expand, mul operations.
TensorProduct : _eval_partial_trace method will split the sub-system to trace. and then based on states inside Tr(|i><k|).  [ This needs more discussions during the next few days and during IRC session.]
Sub-classes of ‘State’ : Need to decide which subclasses need and how it should be done.

Week 5

Symbolic Trace operations and Partial Trace operations.

Week 6

Changes to qapply for L and R operations and any operations that would be needed based on changes so far. (will also fix the bug identified in PR 1312)

Other related learning activities this week.

I tried IPython Notebook and I absolutely love it. Now, I am using that as my command line interface for running sympy commands and understanding current implementation.  The best thing Notebook has done to my workflow is help me save my scratch work and go back whenever I need it. Thanks @ellisonbg.

I did have to jump some hoops to set up Notebook on Ubuntu 11.04, since I had to build a lot of dependencies myself. I plan to blog about it as part of another post.  A minor pain point with it is, I need to drag/drop files I want to work on. Wish it gave me an option to type in the URL to a saved notebook rather than forcing me to open a FileManager window to find file to drag and drop.

Week 1 Report : Initial set of routines for Density Operators

Today I submitted a pull request

What went into this weeks pull request

The framework and routines were inherited from Brian’s github branch.

  • The  _eval_args function was added.  I went back-and-forth on deciding if we needed strong checks to make sure the states used to build density objects should be strictly KetBase and Qubits. But, there were scenarios where just symbols could be used for states, or even QExpr could be used. So, discarded that check.   But, this would mean Density objects could have arbitrary objects for states.  Flip side to this is,  represent() on density objects which do not have a KetBase object does not work very well. For example, having ‘mul’ expressions for ‘state’ creates problems in represent functions. But, my assumption is represent function need not handle such scenarios.                                                                                                                                    Similarly, I went back and forth regarding checking for valid values for probabilities. Then, I dropped those validations as well.
  • Added test routines for all public facing methods in density.py. Some methods from original DensityOp branch are not in this pull request. I will add them back in future requests.
  • I also created a minor pull request for minor printing changes that were in the original densityOp branch. This takes care of changes to the latex() in operator.py. I will add checks for density operator after this pull request is accepted.
  • Added test routines for changes related to density in qapply.py. These checks will have to be extended after I make density operators work well with Qubits.
  • Added doc strings.

Where I spent a my time while trying to accomplish this weeks tasks:

  • Understanding the process-function call flow of _eval_args,   _print methods.
  • Getting familiarized with operator.py , represent(), and qapply().

(The following point is also a question for my next task)

  • The way  _qsympify_sequence(seq) method is implemented, it treats any Qubit() passed as state to Density as a sequence object. Therefore, the Qubit object is lost and a tuple is replaced instead of the Qubit object. This needs to a fixed or a work around decided so that Qubits can be provided as states to Density objects.

My next steps ( plan for next week’s pull request):

  • Discuss with the mentor team and see how to approach the problem with Qubits being converted to sequence. ( in next 2 days )
  • Add remaining functionality into density.py ( entropy, reduced trace operations ) ( should be completed by middle of next week )
  • Blog about the implementation details of changes to tensorproduct.py with respect to what we would need for density operators.  I hope to also have this part implemented by end of next week.
  • Address issues with the current pull request. I plan to have this as the top priority task and work on this every time it comes back to me.


I gave a lightening talk at Google Chicago office this week regarding my GSoC 2012 project and there was lot of interest in Sympy. Particularly, folks were very excited to know about  Sympy Live website which I spoke about in the presentation.

Also, met one of our Sympy contributors Matthew Rocklin  at the meeting. Nice to meet someone you know only as an email-id, in person!

Plan for first 4 weeks : Post 1

As part of first set of steps (first 4 weeks) in the project plan, my initial proposal was to achieve the following specific goals:
(These goals are listed also with respect using the current implementation of density operators at this branch: densityOp branch at ellisongb@github

  • Start with density.py
    Make it work with different bases by aligning the current implementation with representation logic.
  • Come up with an proposal/implementation for density matrices specific to qubits. ( Do we need a specific version for qubits? )
  • Update TensorProduct.py for multi-qubit states.

The above tasks currently has been planned for the first 4 weeks of the project. For each of the above tasks, I will provide 2 sections in this blog and subsequent blog posts. In the first section, I describe my understanding of current implementation and in the second section I list out what is needed (kind of list out requirements, and then propose the implementation idea).

What is currently available in Density.py? ( from the above git branch)

  • Currently, density.py has the basic function prototypes.
    The current density object accepts any kind of input. That is, there is no restriction on objects to be strictly of type ‘State’ or ‘Ket’.
  • Also, when we use Qubit’s as argument to the density object, what gets printed is not accurate. For example,
  • Example of output for Density

  • The doit() method and represent() method do not execute successfully.

Next steps for density.py

  • Add eval() function
    Validate the arguments passed to the constructor. Only instances of type ‘State’ will be accepted.
    If any QExpr is passed as argument, then QExpr will have to be simplified and checked if final QExpr object is an instance of type ‘State’. Alternatively, we could just check if passed states are of type ‘Ket’. This step takes care of creation of density matrices.
  • Update doit() : The current implementation currently errors out. We will work on this to fix it.
  • Update _represent() : The current implementation errors out. Also, the current implementation expands the density operator (thus producing the matrix) before the original represent() method is invoked. The approach, we plan to take is call the represent method for each of the states in the density op.
    Say, Density([ ket1,p1 ] , [ket2, p2], [ket3,p3] ), then would way do change of basis using represent would be to do the following:
    (the following code, is just pseudo-code)

    _represent(self, **options)
      states = []
      for each state in density matrix
       states.append(represent(state, **options)
      return Density(states, probabilities )

    (My understanding is the probabilities of each state should not get affected during change of basis. Is this correct?)

  • Add test cases. Of course, this step will be step 0.

My next blog post will have similar structure of discussion for the next 2 topics. My hope is by end of this week, these details are spec’d out enough so that I can exactly say what I will deliver at end of each of the first 4 weeks.

P.S: I plan to provide detailed plan for remaining tasks as we approach the specific week for corresponding task.

Selected for GSOC 2012

It feels great to be one of the participants chosen to participate in this year’s GSOC.  This blog will continue to have updates regarding my progress through the summer.

Hello GSOC Reviewers!

Hello there!  I plan to use this blog to communicate with the Sympy community regarding the progress I make on the project. I plan to update this blog atleast on a weekly basis, and sometime more frequently if I find something interesting and important to share!