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.