On Tue, Jun 7, 2011 at 1:54 PM, Tomo Lazovich <[email protected]> wrote: > Hi, > > On Tue, Jun 7, 2011 at 3:20 PM, [email protected] > <[email protected]> wrote: >> >> That remark is quite important. In the same spirit I would like to know if >> there are any arguments for using an expression for the representation >> instead of a function (the use of x_1 or x_dummy or whatever seems awkward >> (personal opinion!)). >> > > I agree wholeheartedly as well. As for your question about expressions vs. > functions, I don't think an explicit decision was really made one way or the > other because so far representations have really been thought of in terms of > matrices (stuff for spin operators and gates) rather than continuous > functions. I did not write the classes in cartesian.py, which are the first > ones which return expressions, so perhaps whoever made that decision can > comment. > >> >> Maybe one such argument is that using a function instead of an expression >> breaks the (possible) reuse of code between the implementation for discreet >> and continuous bases. (I'm really shooting in the dark here!) >> >> Anyhow, I would like to know what the others think about that. Using >> functions seems more natural to me (no x_dummies for one). > > I also believe that functions seem a bit more natural as well, and I'm > interested to hear what others think. I think the ultimate goal of this > endeavor is to be able to take an equation, like the Schrodinger equation, > written as just operators and kets of some known system (H|psi> = E|psi> for > a system), and then call represent() on it, with a specified basis, and get > the complete functional form of that equation (with derivatives, etc.). So,
+1, this is the ultimate goal. This would be super awesome if sympy could do such manipulation, or at least be able to represent such expressions as a start. > in that case, it seems to make sense to have representations return > functions. It might even be nice to just have a Wavefunction class for this > purpose. I'd be interested to hear more thoughts on implementation. My own personal approach is the following 1) I try to get the goal done as soon as possible, no matter how hackish the code will be. So I would try to represent the Schroed. equation using kets in sympy, pick some simple Hamiltonian. Try to convert it into some basis (simple one). Then try another basis. See how it goes. 2) Then I would start thinking what the best design is and discuss with other people what they think, invite them to play with the code in 1) and so on. For some very long term projects, this might not be such a good idea to start in a hackish way, but for most things, that works the best, because you can easily spend weeks over designing things, and then realizing, that actually the design is not the right one, because after all features are in, you realize, that some other design is better. Using the 1) and 2) approach, you get all the necessary features first, and then once the whole picture is in, you can create a good design. Brian has spent the most time in this quantum stuff, hopefully he will be able to comment. Ondrej -- You received this message because you are subscribed to the Google Groups "sympy" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/sympy?hl=en.
