Comment #3 on issue 3199 by [email protected]: Finish implementing density
operator/matrix
http://code.google.com/p/sympy/issues/detail?id=3199
For case 1 here are some ideas:
* Representation of the density operator in different bases. For the
general case this logic should use the representation logic on of
states in the density op itself. Have a look at our representation
module for details on how that works.
>>>>>>> As it stands, the represent() does not work with the commit you
>>>>>>> pointed to. Is that right?
>>>>>>> I will spend some more time understanding the representation logic.
>>>>>> The proposal will have info on how this could be done.
* Implementation of a symbolic Tr sympy.Expr. This may already exist
in sympy, but I don't know.
I searched for this, did not find any. Yes, we will need to add
this.
Can I pick some sample sympy.Expr close to this, so that I can
plan on
replicating the same design ideas/principles in the proposal.
* Proper handling of partial trace operations when the states are
TensorProduct instances.
I see that your branch has this file: qubitdensity.py, which has an
implementation for partial trace. We can extend this
for TensorProduct instances as well. I am assuming we probably need
an
child to any new Tr expr object we create, that would handle qubit
specific density op especially for partial trace operations.
* The ability to apply operators to both the bra and ket in a density op.
This will have to do with how we expand the arguments before
applying the
operators. Currently, the qapply() expands all arguments, and that
may
have to be tweaked to make this work. There were some discussion on
how
this should work. May be those points should be taken into
consideration.
http://code.google.com/p/sympy/issues/detail?id=3169&q=expand&colspec=ID%20Type%20Status%20Priority%20Milestone%20Reporter%20Summary%20Stars
* Time evolution equations.
Will need to look more into this. I am more familiar with the
constructs
of quantum computing than the more general constructs of quantum
mechanics. But, I can look into this as I get familiar with other
items
in this list.
For case 2:
* Probably want a special subclass for density operators w qubits.
Right now, I was thinking that is how the current Density class
works,
since it takes the Qubits as the arguments. Should we be abstracting
this?
* Have a look at the above commit for other ideas.
I looked at your current branch, and I am hoping I have gotten
myself
familiar with what is there. Currently, I see that the qapply()
right
now expands the states within Denisty op and returns the final
result
as another Density op object. This may have to of course change
based on
some items above, like, expanding rho into a|alpha><beta| and then
putting them back as a density op.
* Entropy/entanglement measures.
I can start of on this using the qubitdensity.py implementation you
have
currently.
* Specialized partial trace (see above commit).
I was not sure about what you mean by Specialzed partial trace. I
did see
the reduced_density() in the qubitdensity.py
* Proper handling of states that are TensorProducts of multi qubit states.
I will do more research on this and see what kind of support the
current
tensorproduct.py has. I was under the impression this case was handled
right now.
Other items from your prior email:
We could expand the density matrix into its tensor product form and
then expand that further until it is a sum of terms that have the form
a|alpha><beta|. Then qapply would work fine on each of those terms.
The difficulty with that approach is that the final results won't be a
density matrix object - it would be a sum of tensor products.
My previous comment on expanding arguments in qapply() applies to
this
comment as well. If we can have an agreement on which is required
and
if the user can be given some options to choose between these,
then we
should be able to implement both approaches.
When applying operators to density matrices, the operators need to
act on both the L and R sides. We could create a special method of
the density op class that applies an operator to the L and R sides.
We would need to think a bit about the best way of integrating that
with the qapply logic we have in place.
Ok. Looks like we need an option for the user to either do this or
ability to apply operator to either ket or bra(based on your
previous
comment).
--
You received this message because you are subscribed to the Google Groups
"sympy-issues" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/sympy-issues?hl=en.
