Thanks Asaf, for introducing us to the openket framework! I also think
this discussion of API is a great initiative, and I have some general
suggestions:
1) The state objects should be responsible for knowing how operators
affect them.
2) Operator objects should only implement their relation to other
operators.
If we enforce this division of labor between state- and operator-
objects, we get a clean separation of functionality that apply to
operators and functionality that apply to states.
QuantumOperator functionality could include:
- commutator(a,b)
- wicks(expr)
- contraction(a,b)
- cross-product, e.g. L = r x p
- vector summations, e.g. j = l + s, |l-s|<j<|l+s|
- etc.
None of this should depend on the implementation of QuantumState.
State functionality would be of the kind:
- direct product: <a|b>
- product states: |a>|b> = |ab>
- action of operators:
- A|a> = a|a> # |a> should know that it is an eigenstate of A
(as in openket)
- B|a> = B|a> # if |a> doesn't implement the action of B (as
in openket)
- B|a> = n|c> # if |a> isn't an eigenvector of B but
implements the action
- etc.
If we implement a collection of standard operators, such as creation,
annihilation, position, momentum and angular momentum, it will be
really easy to create state classes that have specific properties by
implementing methods like:
MomentumSpaceEigenVector._eval_MomentumOperator(self, op):
return self.p * self
What do you think? Are 1) and 2) useful principles, or can they limit
the possibilities somehow?
Øyvind
--
You received this message because you are subscribed to the Google Groups
"sympy" group.
To post to this group, send email to sy...@googlegroups.com.
To unsubscribe from this group, send email to
sympy+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/sympy?hl=en.
