Øyvind Thanks for joining in this discussion. Your ideas are definitely more than welcomed.
> 1) The state objects should be responsible for knowing how operators > affect them. > 2) Operator objects should only implement their relation to other > operators. Overall I think this seems reasonable. But part of the missing picture is understanding how representation and basis set affects all of this. The reason I say this is that a given operator looks different in different bases. In general, I am not sure it even makes sense to anything additional with the expressions A|a> until you pick a basis. Thus, I almost think the core idea is that operators and states should know what they themselves look like in different bases. > 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. Yes, definitely and most of these things are independent of basis. > 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) In this case I agree that |a> should know it is an eigenstate of A with eigenvalue a. This should be implemented by |a> knowing how A acts on it. > - B|a> = B|a> # if |a> doesn't implement the action of B (as > in openket) Right, but you could pick a basis for B and |a> and carry out the operation in that rep. But I guess that is a bit different: B|a> = Sum(B|i><i|a>, i). Which reduces to I guess the question of how B applies to |i>, which goes back |i> knowing how B acts on it. > - B|a> = n|c> # if |a> isn't an eigenvector of B but > implements the action Right and there are situations where you know what the operator does independent of basis. So I think you are right that it should be up to states to determine how various operators act on it. > - 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 Yep, exactly. And I think this naming convention is the right one: StateClass._eval_OperatorClass. Do you think we should rename _dagger_ to _eval_Dagger? > What do you think? Are 1) and 2) useful principles, or can they limit > the possibilities somehow? I think this sounds great. Tomorrow I will throw up a branch on github with a brief sketch of these ideas. So cool. Thanks! Brian > Ø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. > > -- 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.
