Øyvind,
>> 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> ? Awesome. I really think this is starting to solidify. It will probably take some work to see how all the details work out, but this sounds like a great plan. >> >> > 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. Definitely. The one part that is not clear is when operator actions should be applied automatically. Some choices: * When the operation is basis independent. For example A|a>=a|a>, or the various identities that spin operators obey. * Never. We could always require a use to call an external function like apply_operators to cause these actions to occur. But lets start to implement and see what it looks like. We also might want an option that allows operator actions to be attempted in a particular basis. This would go through and insert identities between each operator and state and try to evaluate the result. >> >> > - 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. Yes, I guess the convention is lowercase so far in sympy. > That is great, thanks! Asaf, what do you think about this plan? Thanks for the feedback. I will have time later today to work on this and post a branch. Cheers, Brian -- 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.
