On 24 Mar, 13:56, Brian Granger <ellisonbg....@gmail.com> wrote: > Ø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.
Yes! This must be the core idea, and more precisely: 1) States need to know how they look in different bases, i.e. |a> and | i> should be able to determine <i|a>. Then if there are complete sets of |i><i| or |a><a|, the basis transformations are defined in terms of the methods in the QuantumState class. 2) Operators on the other hand, can be expressed in any basis for which the action on the basis states is known, and all involved states can determine their inner product. So this can also be reduced to methods of the QuantumState classes. I am not sure if this is always what you want, though, so maybe we should also have objects that represent unevaluated matrix-elements <a|H|i> ? > > > 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. "Independence of basis" is a great criterion for what should be considered "operator functionality" > > > 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. Exactly. I would suggest that the basis transformation in general only should be done if the user ask for it explicitly. > > > - 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? I would say that renaming to _eval_Dagger, would be more consistent with the methodnames in core, but I am not sure if there is an established convention about this. Perhaps _eval_dagger and _eval_operator_class is even better? I don't have strong opinions on this. > > > 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! That is great, thanks! Asaf, what do you think about this plan? cheers Øyvind > > 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 > > athttp://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.
