rhoforsympy

..where we discuss density operators wrt SymPy

Month: May, 2012

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.

Misc:

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.