Plan for first 4 weeks : Post 1

by grdvnl

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
    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 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 ( from the above git branch)

  • Currently, 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

  • 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.