Asaf, > We can certainly change the openket licence, nonetheless I believe > that by taking advantage of sympy we'll use most of the ideas of > opeket but only rewritten pieces of the code. Either way I'll ask my > friend to change it.
Cool, even if we don't use much of the code, this will enable all of us to use that code in developing new things in SymPy. > I've taken a closer look at secondquant.py and noticed that it uses > Mul for inner/outer products and operator application, and by means of > external functions ( apply_operators and apply_Mul) applies the > operators and inner/outer products. I am working on an implementation > that uses this approach. Is there a way to call these functions in the > background automatically? I think this need further thought. Let me think out loud about the design of all of this. In the abstract sense, if you have a set of operators and states: A, B, C |a>, |b>, |c> you don't really know how to apply the operators until you choose a basis: A|a> = Sum(<n|A|m><m|a>, m) Thus, I think the base multiplication operations we are using should not apply the operators. With that said, there *are* cases where a particular subclass of these objects would know how to carry out the multiplication. Thus, I guess I think it depends. I think the general rule should be this: If if is obvious how to carry out an operation (Mul, Sum, etc) *and* every user would always want it to be carried out, then we should do it automatically. This is the approach in SymPy that is used in general and I think it applies here as well. But, I do agree that in some cases this rule will lead us to apply operations automatically. How does that sound? >> It would be great to have a base level quantum module >> that defines symbolic States, Operators, time evolution, delta >> function, etc in a generic manner. Then the quantum computing and >> second quantization package can subclass accordingly. > > I have been thinking that maybe we should agree on the API, in order > for this module to be useful as a basis for second quantization and > quantum computing. I don't know very much about second quantization > but from what I've seen on the code I believe that the openket API can > be quite compatible. Is it clear from the examples I sent how the > module will work or will it be better if I prepare a more explanatory > document? Yes, I have been thinking this as well. I think working out a solid base API would be useful in other areas as well. For example Ondrej are I are working on PDE based solvers for the Schroedinger equation. That framework will have things like states, operators, etc and it would be nice if we could use this infrastructure. In terms of base API, why don't we do the following: * Post a SymPy branch on github. I can do this or you can. Lets add the relevant people as contributors. * Create a new file in the physics directory called dirac.py or braket.py etc. * Start to implement and work out the base API. Here is a start... * Basic objects: Operator Ket Bra BasisSet DiscreteBasisSet ContinuousBasisSet Orthogonal/NonOrthogonal versions of basis sets. * Operations Dagger InnerProduct OuterProduct Sum, Mul of scalar vectors DirectProduct (|a>|b>) Representation of a Bra, Ket, Operator in a given basis. Let me know if you want me to post a branch on git hub for this or if you want to do that and then we can get started. Out of curiosity, where are you located Asaf? 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.
