Hi Robert, I noticed you didn't send this to the sympy list, but since it got forwarded here, here are my replies:
On Thu, Nov 6, 2014 at 9:51 AM, Nikolas Tezak <[email protected]> wrote: > Hey Robert, > thanks for your reply! That’s very cool. > I would very much like to join forces on sympsi, in that case! > I’ll check out the code and get back to you two! > > Regarding explicit and implicit tensor products, I agree that it should be > possible to allow for both. > We’ll figure something out :) > Best, > > > Nik > > > On Nov 5, 2014, at 11:20 PM, Robert Johansson <[email protected]> wrote: > >> Hi Nikolas >> >> Great to hear that you’re interested in finding a common framework for >> symbolic quantum mechanics for QNET and the sympy quantum module! I think >> both projects would benefit from this. >> >> Me and a student here where I work (Eunjong Kim, cc:ed) are also working on >> extensions of the sympy quantum module. Currently our focus on bosonic and >> atomic systems, and we are working on methods for manipulating operator >> expressions, such as performing unitary transformations and generating >> Heisenberg and semiclassical equations of motion. For now we do this work in >> a separate project that we branched out from the sympy.quantum module, which >> we call sympsi: >> >> http://sympsi.github.io >> >> I hope we can contribute this work back upstream to sympy.quantum at some >> point, but for the time being we are doing this in a separate project >> because we needed a faster paced development repository. The activity level >> in sympy.quantum module is very low now, and pull requests takes a long time >> to get reviewed. For example, I currently have a PR with a small fix of a >> issue in the quantum module: >> >> https://github.com/sympy/sympy/pull/8264 It's in. >> >> and it has been few weeks without having received any comments. I don’t mean >> to be critical or anything, but it is difficult to work and make progress >> with sympy.quantum if with this pace of development. So my current solution >> for this is to do experimental work on It is important that you ping reviewers to review your code. I have asked you already to do that, e.g here: https://github.com/sympy/sympy/pull/2692#issuecomment-32912971 We are all busy with our day jobs, just like you are. If you look at the number of PRs in sympy: https://github.com/sympy/sympy/pulls There is over 160 open. Even if I spent only 15 min on each, it would take 40h (i.e. a week full time) to review all of them, so I would have to take a week vacation to do that. However, and that's the beauty of opensource and a community, if each of us only reviews a subset of PRs, then we can actually easily keep reviewing all of them. Robert, you have already established yourself with many PRs in sympy and because I am interested in quantum, all you have to do is to put "@certik" in any PR you post, then I get an email in the inbox, and I almost always reply within a day, usually sooner. Other people, let's say with interest in integration, will ping other people. The best is to ping people who contributed to the area of the code that you are touching in the PR. You can use "git blame" to get an idea. Anyway, if you could please ping us the next time you send a PR, I can guarantee you'll get a better experience. > sympy.quantum in a separate project. Maybe this would not be necessary if > more people get involved in sympy.quantum. But I also think it would be worth > having a discussion on if the quantum module in sympy should really be a part > of sympy or if we could collaborate more easily on symbolic quantum mechanics > with Python in a separate project which has sympy as a dependency. There is > no technical reasons for why the sympy.quantum module has to be included in > sympy, and having it in sympy makes it difficult separately install updates > in the quantum module. As it is now a user that want to use recent features > from the quantum module has to install the development version of sympy from > github. Either way, I’d be happy to work together symbolic quantum mechanics. Yes, that's a valid point, see our conversation above. There are pros and cons of each approach. Some pros of being separate is that you can possibly develop faster as well as only update you module and work with any stable branch of sympy (as you mentioned). Pros of being inside sympy is that you get wider exposure and if it is a code that only gets updated a few times a year, you essentially get free maintenance form the rest of the sympy crew. >> >> Regarding your question about explicit tensor products (quantum module) and >> implicit tensor product (secondquant), and whether it would be possible to >> towards implicit tensor products in the quantum module: Personally I think >> that the quantum module must support both types of formalisms. When working >> only with operators it is convenient to use implicit tensor product, as you >> point out, and currently it is already possible to do this using the fermion >> and boson modules in sympy’s quantum module (as well as in secondquant), >> because different modes can be assigned labels that can be used to >> distinguish the modes (rather than their position in a tensor product). This >> is what I use in most of what I use sympy quantum for. But in my experience >> it is also very useful to allow explicit tensor products of operators in >> when working with different states for different components in composite >> quantum systems. So my vote is for not moving towards one formalism or the >> other, but rather support both of them. It shouldn’t be too difficult to do >> this, since there is already some support for this. >> >> As for the secondquant, I think it is a bit unfortunate to have two separate >> and incompatible frameworks for symbolic quantum mechanics in sympy, and I >> think it would be great if the the features of secondquant eventually could >> be moved into the quantum module, and perhaps then the secondquant module >> could be deprecated. The fermion and boson modules in the quantum module is >> a step in that direction, but there is more work required on this. I think it's always great to try new ideas outside of sympy, since you don't need to get any reviews and you can just try things and experiment with things and figure out what approach is more promising and what approach is less promising. Once you know the design and it stabilized, then it is a good time to send it to sympy, so that it becomes part of sympy and anybody can use it and build upon it. Ondrej -- You received this message because you are subscribed to the Google Groups "sympy" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/sympy. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/CADDwiVC3iusHY7XxR2Q-HbfyBAZ%2BxJO9Vc61miyKuZLDttKmjQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
