[sympy] [JOB] Work full time on Project Jupyter/IPython
Hi all, I wanted to let the community know that we are currently hiring 3 full time software engineers to work full time on Project Jupyter/IPython. These positions will be in my group at Cal Poly in San Luis Obispo, CA. We are looking for frontend and backend software engineers with lots of Python/JavaScript experience and a passion for open source software. The details can be found here: https://www.calpolycorporationjobs.org/postings/736 This is an unusual opportunity in a couple of respects: * These positions will allow you to work on open source software full time - not as a X% side project (aka weekends and evenings). * These are fully benefited positions (CA state retirement, health care, etc.) * You will get to work and live in San Luis Obispo, one of the nicest places on earth. We are minutes from the beach, have perfect year-round weather and are close to both the Bay Area and So Cal. I am more than willing to talk to any who interested in these positions. Cheers, Brian -- 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 sympy+unsubscr...@googlegroups.com. To post to this group, send email to sympy@googlegroups.com. 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/fcb9e941-9b92-46e7-9136-6fa3d3d6b72d%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [sympy] Writing a fast pattern matcher, updates and questions
Awesome! That is one of the missing pieces for sympy for sure!
I would definitely have a look at the pattern matching of Mathematica,
to see what kinds of things are useful and needed for that type of
thing.
Cheers,
Brian
On Wed, Nov 26, 2014 at 3:19 PM, James Crist crist...@umn.edu wrote:
All,
In my spare time, I've been working on implementing a fast pattern matcher
that accounts for Associative and Commutative symbols. It's going to be a
while before I'm ready to release the code (it needs some serious cleanup),
but as of now it is partly functional. Some notation:
T = set of known patterns. A trie like data structure is used to preprocess
these patterns to aid in fast matching.
s = expression to be matched
x, y = variables
a, b, c = constants
Currently the matcher can determine what patterns in T match s, in the
presence of associative and commutative symbols, as long as the pattern is
linear. By linear, I mean no repeated *variable* symbols (`x + y` is
acceptable, `x + x` is not). If no associative and commutative symbols are
present, it can also determine a match substitution to make `s` equivalent
with the pattern.
Some design questions before I continue work:
- Is there any use for just determining what patterns match, without
generating a match substitution? Determining if a match exists is faster
than determining a specific substitution. However, in the presence of
nonlinear patterns a substitution needs to be found to verify the match is
valid. This decision determines how tightly coupled the two algorithms will
be.
- Is there need for nonlinear patterns? I plan to account for them, but they
make the algorithm a bit more complicated. Nonlinear, AC pattern matching is
NP complete. Linear AC pattern matches can be found in polynomial time.
- In a general case, there can be many substitutions that match a specific
pattern mod AC. For example, given `t = x*y`, and `s = a*b*c`, this can
match with {x: a*b, y: c}, or {x:a, y: b*c}, etc... This is easy to account
for, and can be done lazily. Api-wise, are there cases where generating more
than one matching substitution are needed?
- The algorithm lazily determines matches. Currently preference is given to
matching variables before constants, but it could go the other way around.
i.e. if T = {a + b, x + b}, and s = a + b, then the matcher will find `x +
b` before `a + b`. I'd rather not make this configurable, as it complicates
things. The question is, do we want the most general match first, or the
most specific?
- At the moment, the code is completely removed from dependence on sympy,
and can function on its own. As such, I'm planning on making it a separate
library that can be used by SymPy as a dependency. I understand we were
against that in the past, but this may be changing? I'd rather not maintain
two separate codebases.
- There's a `commutative` assumption in sympy, but there doesn't seem to be
an `associative` one. How can I check if a function/operator is associative?
Does this information need to be kept elsewhere?
- Jim
--
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 sympy+unsubscr...@googlegroups.com.
To post to this group, send email to sympy@googlegroups.com.
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/42d9511d-e963-416f-9d4e-3e0435461422%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--
Brian E. Granger
Cal Poly State University, San Luis Obispo
@ellisonbg on Twitter and GitHub
bgran...@calpoly.edu and elliso...@gmail.com
--
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 sympy+unsubscr...@googlegroups.com.
To post to this group, send email to sympy@googlegroups.com.
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/CAH4pYpTm%3DhK487L1TKtg7xxaSj3SuK53EKWF55ZThb9QjwUBng%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Re: [sympy] astsearch
Yes, I saw this - very beautiful! On Wed, Apr 30, 2014 at 9:30 AM, Aaron Meurer asmeu...@gmail.com wrote: Some people on this list might find this useful. http://takluyver.github.io/posts/astsearch-code-searching-that-knows-about-code.html We often grep the codebase to do refactorings, or fix some API, or whatever. This uses Python's ast to search, meaning it will filter out false positive, and should also work with things that span multiple lines (and you don't have to worry about whitespace). As an example, to find all instances of .args in code (as opposed to strings and comments), you could do astsearch ?.args sympy/ Aaron Meurer -- 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 sympy+unsubscr...@googlegroups.com. To post to this group, send email to sympy@googlegroups.com. 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/CAKgW%3D6JQpXRF0Pmd-BvXjXpvShLGWNs7BicW0%3DyfO_JdxDsz3Q%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout. -- Brian E. Granger Cal Poly State University, San Luis Obispo bgran...@calpoly.edu and elliso...@gmail.com -- 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 sympy+unsubscr...@googlegroups.com. To post to this group, send email to sympy@googlegroups.com. 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/CAH4pYpSLgRAZ9rk-bLAbc1pcGYHBkf6wAL4QB1fAHmM844fgjA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [sympy] Questions about the goals of CSymPy
I too feel that csympy should implement the absolute minimum possible for it to be fast. All actual mathematical algorithms should remain in sympy. Trying to pull lots of algorithms into csympy will fail - not that many people want to write complex mathematical algorithms in C++. On Tue, Apr 22, 2014 at 5:06 PM, Aaron Meurer asmeu...@gmail.com wrote: On Tue, Apr 22, 2014 at 12:05 PM, Ondřej Čertík ondrej.cer...@gmail.com wrote: Hi Aaron, Those are good questions. Here are the answers: On Tue, Apr 22, 2014 at 10:13 AM, Aaron Meurer asmeu...@gmail.com wrote: I have some high level questions about CSymPy. - What are the goals of the project? The goals of the project are: * Fastest symbolic manipulation library, compared to other codes, commercial or opensource (Sage, GiNaC, Mathematica, ...). * Extension/complement to SymPy * If the above two goals allow, be able to also call it from other languages easily and efficiently (Julia, Ruby, Mathematica, ...) As to technical solution: the core should be a C++ library, which can depend on other compiled libraries if needed. The core should not depend on Python or Ruby or Julia, but rather be just one language, C++. That lowers the barrier of entry significantly, compared to a big mix of C++, Cython and Python, makes it easier to make things fast (you don't need to worry about Python at all). The Python (and other languages) wrappers should be just a thin wrappers around the C++ core (=just better syntax). There might be other technical solutions to this, but I know that I can deliver the above goals with this solution (and I failed to deliver with other solutions, like writing the core in Cython). So that's why we do it this way. Also, by being just a C++ library, other people can use it in their projects. I hope to get interest of much broader community that way, who can contribute back (somebody will need fast symbolic manipulation in Julia, so they can just use CSymPy with Julia wrappers, and contribute improvements back). - What are the things that should definitely go in CSymPy? At the moment: all things to make specific applications fast, in particular PyDy. For that, it needs basic manipulation, differentiation, series expansion (I think) and matrices. That's all roughly either done, or on the way. Of course, lots of polishing is needed. I think that's already too much. Why is the series expansion slow in SymPy? Is it because the algorithms are slow? If so, then implementing the same inefficient algorithms in CSymPy won't help. They will be faster, but for large enough expressions they will still slow down. Is it because the expression manipulation is slow? In that case, if CSymPy has faster expression manipulation, then just use those expressions, but use the SymPy series algorithms. My points are: - I think CSymPy should focus on making expression manipulation fast (i.e., the things that are the inner loop of any symbolic algorithm). It should not reimplement the symbolic algorithms themselves. Those are implemented in SymPy. If they use the CSymPy objects instead of the SymPy objects, they will be faster. - I would focus more on making CSymPy interoperate with SymPy and less on reimplementing things that are in SymPy in CSymPy. Once there is interoperation, we can see what is still slow, and then (and only then) implement it in C++. - What are the things that should definitely not go in CSymPy? Things that don't need to be fast. Things like limits. Also things that are in SymPy, where CSymPy can be used as a drop in replacement for the engine: PyDy, some stuff in physics, and so on. There is no need to rewrite PyDy in C++. Also most user's code would stay in Python. They can just optionally change to CSymPy for some intensive calculation, then finish the thing with SymPy. - How will CSymPy be architectured to allow things to happen in CSymPy when they can but fallback to SymPy when they cannot. Currently you can simply mix and match SymPy and CSymPy expressions. So you simply convert an expression to SymPy to do some advanced manipulation, and convert to CSymPy to do some fast manipulation. I am open to suggestions how to improve this. My main concern here is that CSymPy has not clear separation from SymPy, and as a result it will end up growing larger and larger, until it becomes an independent CAS (which is fine if that's the goal, but my understanding was that it was supposed to be just a small fast core). The goals are written above. I am myself concentrating on speed, that's what I really want to nail down. And then enough features so that it's useful for all the people who found SymPy slow. However, let's say somebody comes and reimplements the Gruntz algorithm in CSymPy. Should we reject such a PR? My answer is that if the code is nice, maintainable, much faster than SymPy and has the same or similar features, I am ok with merging it.
Re: [sympy] Add multiple dispatch as external dependency
I am strongly +1 on this idea. On Tue, Apr 1, 2014 at 7:10 PM, Matthew Rocklin mrock...@gmail.com wrote: Hi Everyone, i'd like to add the multipledispatch project as an external dependency to SymPy. As a reminder, SymPy currently doesn't depend on any external libraries, so this particular move also represents a policy shift. This potential policy shift follows substantial discussion, notably at https://github.com/sympy/sympy/issues/7339 . There are good reasons for and against external dependencies (I recommend checking out the header of the mentioned issue). I'm now specifically proposing that we depend on multipledispatch which might have other more specific benefits and drawbacks. Even if someone is for dependencies they might not be for this particular dependency. Any thoughts? Now would be a good time to voice concern. One example use of multipledispatch in SymPy is at #2979 . Best, -Matt -- 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 sympy+unsubscr...@googlegroups.com. To post to this group, send email to sympy@googlegroups.com. 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/CAJ8oX-Gi8uGcXF6i73tGFp71%2B02mfJW2d42MUvADkRvCsZHRRw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout. -- Brian E. Granger Cal Poly State University, San Luis Obispo bgran...@calpoly.edu and elliso...@gmail.com -- 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 sympy+unsubscr...@googlegroups.com. To post to this group, send email to sympy@googlegroups.com. 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/CAH4pYpSx%3DDt3TqF3dAS0LrjAM1XHa_-3xUWuxut89cURYoE3XQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [sympy] Add multiple dispatch as external dependency
I strongly think that multipledispatch should be a separate project. There is a good chance we would use this over time in IPython and I definitely plan on using in various codes I write outside of SymPy. It would probably be a good idea to get some good review done on multipledispatch though before SymPy starts to rely on it. On Tue, Apr 1, 2014 at 8:09 PM, Aaron Meurer asmeu...@gmail.com wrote: I think some questions should be answered first. I think we're all convinced of the technical merits, so I won't touch on those. What are your plans for multiple dispatch as a project? Why can't this just be included in SymPy? Do any other projects use multipledispatch, to your knowledge? How stable is the API? Will we need to worry about compatibility breaks no version mismatches? Aaron Meurer On Apr 1, 2014, at 9:10 PM, Matthew Rocklin mrock...@gmail.com wrote: Hi Everyone, i'd like to add the multipledispatch project as an external dependency to SymPy. As a reminder, SymPy currently doesn't depend on any external libraries, so this particular move also represents a policy shift. This potential policy shift follows substantial discussion, notably at https://github.com/sympy/sympy/issues/7339 . There are good reasons for and against external dependencies (I recommend checking out the header of the mentioned issue). I'm now specifically proposing that we depend on multipledispatch which might have other more specific benefits and drawbacks. Even if someone is for dependencies they might not be for this particular dependency. Any thoughts? Now would be a good time to voice concern. One example use of multipledispatch in SymPy is at #2979 . Best, -Matt -- 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 sympy+unsubscr...@googlegroups.com. To post to this group, send email to sympy@googlegroups.com. 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/CAJ8oX-Gi8uGcXF6i73tGFp71%2B02mfJW2d42MUvADkRvCsZHRRw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout. -- 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 sympy+unsubscr...@googlegroups.com. To post to this group, send email to sympy@googlegroups.com. 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/-6231458978799167094%40unknownmsgid. For more options, visit https://groups.google.com/d/optout. -- Brian E. Granger Cal Poly State University, San Luis Obispo bgran...@calpoly.edu and elliso...@gmail.com -- 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 sympy+unsubscr...@googlegroups.com. To post to this group, send email to sympy@googlegroups.com. 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/CAH4pYpScS99k9X0j6B2GHZW-WM%3DoUquwcp71dkBiX8w9DE3ZEg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [sympy] Can we call ourselves a full-featured CAS?
We are! On Fri, Mar 14, 2014 at 2:44 PM, Matthew Rocklin mrock...@gmail.com wrote: From Wikipedia: The stated goals of the library are to become a full-featured computer algebra system and... From SymPy's tutorial heading It aims to become a full-featured computer algebra system (CAS) while... Are we not a full-featured CAS? Does such a thing exist? Maybe there is better language here. The current language makes the project sound immature. -- 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 sympy+unsubscr...@googlegroups.com. To post to this group, send email to sympy@googlegroups.com. 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/CAJ8oX-FFA%2BDtzLjR3GVFEr87CQYivz62xiQOSLCX1wQZK2nDUQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout. -- Brian E. Granger Cal Poly State University, San Luis Obispo bgran...@calpoly.edu and elliso...@gmail.com -- 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 sympy+unsubscr...@googlegroups.com. To post to this group, send email to sympy@googlegroups.com. 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/CAH4pYpT2nMJDX%2BxG-BYu%2BfF6ZSa3oehgjX8B4SqWo-O0%2B5%2Bdeg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [sympy] Realizing Topological Quantum Computation through Category Theory
Amit, Thanks for your interest. While I am very much interested in seeing the quantum computing capabilities of SymPy improve, I think this particular proposal is out of scope for the project. * The material is advanced enough that there is no one of the SymPy team that would be capable to mentoring this project. I am probably the closest (Physics professor, focusing on quantum mechanics), but I have absolutely no background in this stuff. This point is extremely important because we have found that perhaps the most important ingredient for a successful GSoC experience is an active mentor who has a deep understanding of the material. * The material is specialized enough that I don't think it belongs in SymPy, even if we had a mentor for it. Honestly, even the general quantum computing stuff already borders on being too specialized for SymPy. Were I to do it again today, I would probably make the quantum computing stuff a separate package. Oh, well. Given these two factors, I think the best path forward for you is to develop a separate package for topological quantum computing that uses SymPy, but is separate. That is one of the great things about SymPy - you can easily extend it in separate projects/packages. I know that does't help you get GSoC funding for this though :( Cheers, Brian On Sun, Feb 23, 2014 at 12:15 PM, Amit bitsjamada...@gmail.com wrote: Hello , I am Amit. I would like to discuss the implementation of modular tensor categories for realization of Topological Quantum Computation. In Topological Quantum Computation we use anyon braiding (which develops a phase) to construct quantum gates which are nothing but unitary transforms. The entire process of anyon braiding can be mathematically modeled by representation of modular tensor categories. I have attached the article through which I have gone through for understanding the implementation in CAS. In addition to what is already present, most of the work is on matrices. The 2 Vect spaces are isomorphic to whole numbers, 1 cells are represented by matrices and 2 cells are represented by inner matrices (or 2 matrices) i.e., matrices inside matrices. Most of the implementation is by using the properties of matrices and extending the present implementation of matrices. The implementation then tested the Fibonacci model by mentioning the fusion rules. I would like add this functionality to Sympy and if possible carry it out as a part of GSoC 2014. According to my understanding the implementation is mostly mathematical but the physical extension is to TQC by testing the Fibonacci model. I request the community to comment on this. Thanks. File : http://ora.ox.ac.uk/objects/uuid%3Ac9b6eaf8-29d4-4637-a576-5a35d3c957bb/datastreams/THESIS01 -- 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 sympy+unsubscr...@googlegroups.com. To post to this group, send email to sympy@googlegroups.com. 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/281d1065-f0e0-40bc-ab6b-60fccede626c%40googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- Brian E. Granger Cal Poly State University, San Luis Obispo bgran...@calpoly.edu and elliso...@gmail.com -- 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 sympy+unsubscr...@googlegroups.com. To post to this group, send email to sympy@googlegroups.com. 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/CAH4pYpSb0VPMvvV52hHnSq2S_vntDTqZgJY%2BRSvOyqNd33or8g%40mail.gmail.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [sympy] GSoC 2014: Symbolic Quantum Computing
Yes, this is not on the quantum computing stuff, but there is a ton to do on the continuous rep stuff. That PR still requires a ton of work and design thinking, but it is a great place to start. On Sun, Jan 26, 2014 at 1:13 AM, F. B. franz.bona...@gmail.com wrote: On Saturday, January 18, 2014 1:15:49 AM UTC+1, Aaron Meurer wrote: There was one from a GSoC project but I can't find it (I guess it was closed). Did you mean this one? https://github.com/lazovich/sympy/tree/represent2 I had a look at this some time ago, there are several merge conflicts now, as the quantum module has been independently edited by other contributors. In any case, it would be nice to complete the support for continuous operators. -- 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 sympy+unsubscr...@googlegroups.com. To post to this group, send email to sympy@googlegroups.com. Visit this group at http://groups.google.com/group/sympy. For more options, visit https://groups.google.com/groups/opt_out. -- Brian E. Granger Cal Poly State University, San Luis Obispo bgran...@calpoly.edu and elliso...@gmail.com -- 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 sympy+unsubscr...@googlegroups.com. To post to this group, send email to sympy@googlegroups.com. Visit this group at http://groups.google.com/group/sympy. For more options, visit https://groups.google.com/groups/opt_out.
Re: [sympy] ipython notebook in sympy gamma
The notebook cannot be run on Google App Engine: * Tornado doesn't run. * They can't proxy WebSockets. In order to run IPython Notebooks in the cloud you will have to build a complex cloud based architecture on Amazon/Rackspace that deploys notebook servers on isolated VMs or LXC/Docker containers. It can be done (see Wakari), but is a very non-trivial project. Based on this I would just go with the first idea. On Wed, Jan 22, 2014 at 10:22 PM, SAHIL SHEKHAWAT sahilshekhawa...@gmail.com wrote: For some time now i have been working to integrate ipython notebook in sympy gamma, and i have come up with two ways and now i want to know which one is better so that i can send it as pull request. First: code to generate just the ipython format json file which i have done to a certain extent already, by taking reference from ipython (obviously as it is specific to ipython) its advantage is that it is be of just few kbs and it just does what we want. Second: entire ipython repository can be used as a submodule and we can provide chunks of our result's card's codes to it.i am not sure whether tornado can be run on google app engine. its advantage would be that it will run the ipython notebook server which enables the user to change the input if he wants to as DAVID said. But the problem with first is simply the lack of any additional feature..we want it to create ipynb file and it does.. i have written significant codes on the first one though it is not complete yet but now as i have come with this second idea , i want to ask which is a good one so that i can work on the same.. i think first one will be complete in a day or two... i had to get familiar with the ipython codes and thats why i took this much time..but now as i have come with something..help me -- 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 sympy+unsubscr...@googlegroups.com. To post to this group, send email to sympy@googlegroups.com. Visit this group at http://groups.google.com/group/sympy. For more options, visit https://groups.google.com/groups/opt_out. -- Brian E. Granger Cal Poly State University, San Luis Obispo bgran...@calpoly.edu and elliso...@gmail.com -- 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 sympy+unsubscr...@googlegroups.com. To post to this group, send email to sympy@googlegroups.com. Visit this group at http://groups.google.com/group/sympy. For more options, visit https://groups.google.com/groups/opt_out.
Re: [sympy] GSoC 2014: Symbolic Quantum Computing
Sachith, Hi, welcome. Thanks for getting in touch with us. There isn't really much work going on with the Quantum Computing stuff right now, but there is definitely a lot to work on. It would require a lot of initiative on your part though to study the code and come up with good ideas as to the next steps. I would start by looking through the code and trying to understand how it works. Then I would start to build a list of improvements that could be made and bring them to us. The open pull requests that Aaron pointed to are also a great place to start. Cheers, Brian On Fri, Jan 3, 2014 at 6:53 AM, Sachith Seneviratne sachith...@gmail.com wrote: Hello everyone, I am Sachith Seneviratne. I am currently a 2nd year undergraduate studying Computer Science and Engineering at University of Moratuwa, and I'm also a 4th year at the College of Chemical Sciences (where I've followed quite a few courses on quantum mechanics and the like). I'd like to contribute to SymPy through the GSoC this year. I completed a course on Quantum Computation (from UC Berkeley) on Coursera last year and found it really interesting, so I thought I'd try out for the quantum computing project. Where should I start? Thanks, Sachith -- 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 sympy+unsubscr...@googlegroups.com. To post to this group, send email to sympy@googlegroups.com. Visit this group at http://groups.google.com/group/sympy. For more options, visit https://groups.google.com/groups/opt_out. -- Brian E. Granger Cal Poly State University, San Luis Obispo bgran...@calpoly.edu and elliso...@gmail.com -- 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 sympy+unsubscr...@googlegroups.com. To post to this group, send email to sympy@googlegroups.com. Visit this group at http://groups.google.com/group/sympy. For more options, visit https://groups.google.com/groups/opt_out.
Re: [sympy] qasm parser
Fantastic!
On Thu, Jul 18, 2013 at 12:20 PM, Rick Muller rpmul...@gmail.com wrote:
I created a new branch in my fork that contains the start of a qasm parser.
If you're interested in this, it's available at:
https://github.com/rpmuller/sympy/blob/qasm_parser/sympy/physics/quantum/qasm.py
Right now it doesn't do all that much. I plan to add a few more gates
(X_pi/2, Z_pi/2, S, T), at which point the functionality we have should be
basically useful.
However, the big thing missing is the ability to define a gate in qasm using
the 'def' command. Example 4 from Chuang's page is:
def c-S,1,'S'
def c-T,1,'T'
qubit j0
qubit j1
qubit j2
h j0
c-S j1,j0
c-T j2,j0
nop j1
h j1
c-S j2,j1
h j2
swap j0,j2
We can make gates on the fly by defining a new class, e.g.
class VGate(OneQubitGate):
gate_name = 'V'
gate_name_latex = u'V'
class SqrtX(OneQubitGate):
gate_name = 'sqrt-X'
gate_name_latex = u'\sqrt{X}'
But I don't know how do define a function that does this, without defining
arguments or modifying the object after creation, both of which I understand
are forbidden in sympy operators.
Any thoughts?
--
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 sympy+unsubscr...@googlegroups.com.
To post to this group, send email to sympy@googlegroups.com.
Visit this group at http://groups.google.com/group/sympy.
For more options, visit https://groups.google.com/groups/opt_out.
--
Brian E. Granger
Cal Poly State University, San Luis Obispo
bgran...@calpoly.edu and elliso...@gmail.com
--
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 sympy+unsubscr...@googlegroups.com.
To post to this group, send email to sympy@googlegroups.com.
Visit this group at http://groups.google.com/group/sympy.
For more options, visit https://groups.google.com/groups/opt_out.
Re: [sympy] Thought on implementing measurements in sympy/physics/quantum/circuitplot.py
I think that sympy, once we add some additional gate types, will definitely be the best way of expressing quantum circuits...but I am pretty biased... Cheers, Brian On Mon, Jul 15, 2013 at 7:28 AM, Rick Muller rpmul...@gmail.com wrote: Good Introductory Books/Articles Yeah, that's the definitive book. It's known as the Mike Ike book, Quantum Computation and Quantum Information, by Nielsen and Chuang. It's not exactly introductory, but I wouldn't imagine that anyone making contributions to Sympy would have a hard time with it. It's long, and it's expensive, but it's by far the best single volume on QIS. I own 3 copies of it. Nearly as good are John Preskill's lecture notes on quantum computing. These aren't quite as easy to follow, but they're free. Some guys from a national lab that Ondrej may have heard of published a pretty good introduction 10 years ago here. I can expand the notes on the wiki. Remind me if I forget. Qasm2circ = I've looked through the python converter on Chuang's page. It does some of what we want, but I think it's easier to just implement this ourselves. I don't think qasm is well defined enough to use as an intermediate graph format, and it has other things in it that aren't necessarily relevant, at least in the way I'm doing things now, like the \nop operator. I could be wrong on this, though. Maybe we should revisit this once the initial qasm parser is done. On Sunday, July 14, 2013 10:16:19 PM UTC-6, Aaron Meurer wrote: On Sun, Jul 14, 2013 at 9:47 PM, Ondřej Čertík ondrej...@gmail.com wrote: Cool! What is some good introductory book, so that I can understand more details? I read the intro (free) chapter from: http://www.squint.org/qci/ That's the book that was recommended to me by someone (I think it may have been Brian). I read the first few chapters. It was awhile ago, but I remember that at the time I could understand enough of the basic idea to understand what was going on in these circuits. Aaron Meurer but that's not enough. Do you think that's a good book, or is there some other good resource to learn more about the quantum computing? Ideally we should have some basic intro on this page somewhere: http://docs.sympy.org/0.7.3/modules/physics/quantum/index.html#quantum-computation I only understand the basic idea, that you have some quantum state like alpha*|0+beta*|1 and then you apply 2x2 matrices (gates) that transform it. But it's not quite clear to me how the circuits work and how it could be used. My next question is whether what you want is just implemented by this library: http://www.media.mit.edu/quanta/qasm2circ/ Or whether your idea is to integrate it more with the quantum framework in sympy. For example, should we use the qasm as an intermediate representation for the graph? Ondrej On Sun, Jul 14, 2013 at 8:22 PM, Rick Muller rpmu...@gmail.com wrote: Okay, the first round of this is done, and I updated the IPython notebook at: http://nbviewer.ipython.org/5843312 It now doubles the circuit wires once a wire has been measured. Have to now do all the control wires hanging off this doubled. But I'll do this tomorrow. On Sunday, July 14, 2013 5:52:46 PM UTC-6, Rick Muller wrote: On Sunday, July 14, 2013 5:49:45 PM UTC-6, Aaron Meurer wrote: Aaron (although I am currently in Austin). Sorry 'bout that. Some days all the A's run together. It would also probably be nice to write a function that can convert a qasm file to a SymPy quantum object. In the works, although I'm not going to do much work on it until I finish the drawing stuff. Quantum circuits are just much too hard to print out right now. -- 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 sympy+un...@googlegroups.com. To post to this group, send email to sy...@googlegroups.com. Visit this group at http://groups.google.com/group/sympy. For more options, visit https://groups.google.com/groups/opt_out. -- 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 sympy+un...@googlegroups.com. To post to this group, send email to sy...@googlegroups.com. Visit this group at http://groups.google.com/group/sympy. For more options, visit https://groups.google.com/groups/opt_out. -- 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 sympy+unsubscr...@googlegroups.com. To post to this group, send email to sympy@googlegroups.com. Visit this group at http://groups.google.com/group/sympy. For more options, visit
Re: [sympy] Thought on implementing measurements in sympy/physics/quantum/circuitplot.py
Rick, this is fantastic! On Mon, Jul 15, 2013 at 1:02 PM, Rick Muller rpmul...@gmail.com wrote: The second round is now done: controlled wires now successfully double after measurement. Everything that I wanted to get working in the example page now works: http://nbviewer.ipython.org/5843312 Now that we have working measurement, I think the circuit plotting is now officially useful. I may just submit a PR for these changes, without tackling the stacked gates or the qasm interpreter at this stage. Thoughts on this? I realize the circuits don't render perfectly, but I wanted to get the basic functionality working before tweaking it. On Sunday, July 14, 2013 8:22:15 PM UTC-6, Rick Muller wrote: Okay, the first round of this is done, and I updated the IPython notebook at: http://nbviewer.ipython.org/5843312 It now doubles the circuit wires once a wire has been measured. Have to now do all the control wires hanging off this doubled. But I'll do this tomorrow. On Sunday, July 14, 2013 5:52:46 PM UTC-6, Rick Muller wrote: On Sunday, July 14, 2013 5:49:45 PM UTC-6, Aaron Meurer wrote: Aaron (although I am currently in Austin). Sorry 'bout that. Some days all the A's run together. It would also probably be nice to write a function that can convert a qasm file to a SymPy quantum object. In the works, although I'm not going to do much work on it until I finish the drawing stuff. Quantum circuits are just much too hard to print out right now. -- 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 sympy+unsubscr...@googlegroups.com. To post to this group, send email to sympy@googlegroups.com. Visit this group at http://groups.google.com/group/sympy. For more options, visit https://groups.google.com/groups/opt_out. -- Brian E. Granger Cal Poly State University, San Luis Obispo bgran...@calpoly.edu and elliso...@gmail.com -- 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 sympy+unsubscr...@googlegroups.com. To post to this group, send email to sympy@googlegroups.com. Visit this group at http://groups.google.com/group/sympy. For more options, visit https://groups.google.com/groups/opt_out.
Re: [sympy] Multiple dispatch in SymPy
On Wed, Jul 3, 2013 at 1:42 PM, Ondřej Čertík ondrej.cer...@gmail.com wrote: On Wed, Jul 3, 2013 at 1:48 PM, Aaron Meurer asmeu...@gmail.com wrote: Brian, I think you dropped off list. Forwarding to sympy. Aaron Meurer On Wed, Jul 3, 2013 at 2:29 PM, Brian Granger elliso...@gmail.com wrote: I think that having multiple dispatch is something that is needed within SymPy. Multiple people have run into the difficulties with providing custom Add/Mul logic for their new types. In quantum, we just punted and used the builtin Add/Mul logic, but it was a bad compromise to make. For this, I think looking at Mathematica is really important. This is handled by Mathematica's Rules and Patterns which are documented here: http://reference.wolfram.com/mathematica/guide/RulesAndPatterns.html http://reference.wolfram.com/mathematica/tutorial/Introduction-Patterns.html If we don't have first class, nested and general pattern matching, we can't do multiple dispatch. The case in point is classes that accept *args such as Add and Mul. Good fast pattern matching would also allow us to do much of the logic in Add/Mul constructors using patterns: Add(x_, x_) - 2*x_ Mul(x_, x_) - x**2 Pattern matching is another way to implement CAS, but I am actually not sure this is how Mathematica works inside. Also in pure Python, this might be really slow (I don't know). I don't see all the little details for pattern matching approach. I think I can see more of the details for the sympy approach though. etc. Summary - simple type based dispatch won't do - we need full blown pattern matching and transformation logic. Why wouldn't simple type based dispatch work? You might be right, I just want to understand the problem more. For example take a quantum time evolution operator exp(-I*t*H). What if I wanted to develop custom logic for that operator. Simply matching on type type (exp) won't work. You need to be able to say: exp(-I*Numer(x_)*HermitianOperator(y_)) That requires pattern matching... To answer Aaron's question: On Wed, Jul 3, 2013 at 12:58 PM, Aaron Meurer asmeu...@gmail.com wrote: So, going back to what we discussed the first time we met in Los Alamos, how would you reimplement something like the oo logic so that it lives entirely in the Infinity class, not in Add.flatten (say for simplicity, oo + 3 should go to oo, but oo + 3*I should remain as oo + 3*I)? This, and another example is x + O(x). Let's stick to oo + 3. This is a very good question and it is one of the details that I don't know the answer 100% yet. But I feel it is solvable. The general idea is that you create a new type, let's say Infinity and register mul, add, div, sub, pow using dispatch, which specify how your new type should be handled. In particular, it would look something like: @dispatch(Infinity, Basic) def mul(a, b): if isinstance(b, Integer): return a else: return Add(a, b) But Mul is not a binary operator in SymPy - we could make it so and build the overall *args version by repeatedly calling the binary version. That would be nice... and would somewhat help our situation... This covers most usecases for oo, since when you construct it in Python, you always use the two argument mul(a, b). Also when Add is constructed, the algorithm simply takes one term at a time and adds it to what is in Add already. So those are all binary operations that could be overridden in principle. For example a faster core might decide for speed reasons to not allow oo and O(x) terms. Then multiple dispatch would pretty much make sure that either the fast core will be used if you do add(x, y), but slow and more general sympy core will be used if you do add(x, oo). I think the best would be to create a demo (from scratch) where we can play with these ideas. Hopefully I'll get to this eventually. Ondrej Cheers, Brian On Wednesday, July 3, 2013 10:27:19 AM UTC-7, Aaron Meurer wrote: No, Add(x, y, z, t) is not just used for fast construction. Any algorithm that recurses through an expression tree and rebuilds things will rebuild an Add in that way, using expr.func(*expr.args). Aaron Meurer On Wed, Jul 3, 2013 at 12:22 PM, Ondřej Čertík ondrej...@gmail.com wrote: On Wed, Jul 3, 2013 at 11:15 AM, Aaron Meurer asme...@gmail.com wrote: I don't think it's so easy, because Add has *args. If you are talking about things like: In [2]: Add(x, x, x, y, x, x) Out[2]: 5⋅x + y Then those are of course needed for fast construction many terms into on Add, but this not really exposed to user's code and it is used inside things like expand(). As such, we can provide a special static method or function for doing the same. On the other hand, if you write: x + x + x + y + x + x in Python, then Python itself will call Symbol.__add__ etc., so this would work well with our new dispatch. -- You received this message because you
Re: [sympy] Multiple dispatch in SymPy
Here is another idea that might help: What if we *always* mapped the *args logic for operators like Mul/Add to the binary ones: if len(args)==2: self.dispatch(*args) else: return Mul(Mul(args[0],args[1]),args[2]) etc Then we could focus on the rules and patterns for binary versions. This doesn't solve the issue of needing pattern matching... On Wed, Jul 3, 2013 at 2:19 PM, Brian Granger elliso...@gmail.com wrote: On Wed, Jul 3, 2013 at 1:42 PM, Ondřej Čertík ondrej.cer...@gmail.com wrote: On Wed, Jul 3, 2013 at 1:48 PM, Aaron Meurer asmeu...@gmail.com wrote: Brian, I think you dropped off list. Forwarding to sympy. Aaron Meurer On Wed, Jul 3, 2013 at 2:29 PM, Brian Granger elliso...@gmail.com wrote: I think that having multiple dispatch is something that is needed within SymPy. Multiple people have run into the difficulties with providing custom Add/Mul logic for their new types. In quantum, we just punted and used the builtin Add/Mul logic, but it was a bad compromise to make. For this, I think looking at Mathematica is really important. This is handled by Mathematica's Rules and Patterns which are documented here: http://reference.wolfram.com/mathematica/guide/RulesAndPatterns.html http://reference.wolfram.com/mathematica/tutorial/Introduction-Patterns.html If we don't have first class, nested and general pattern matching, we can't do multiple dispatch. The case in point is classes that accept *args such as Add and Mul. Good fast pattern matching would also allow us to do much of the logic in Add/Mul constructors using patterns: Add(x_, x_) - 2*x_ Mul(x_, x_) - x**2 Pattern matching is another way to implement CAS, but I am actually not sure this is how Mathematica works inside. Also in pure Python, this might be really slow (I don't know). I don't see all the little details for pattern matching approach. I think I can see more of the details for the sympy approach though. etc. Summary - simple type based dispatch won't do - we need full blown pattern matching and transformation logic. Why wouldn't simple type based dispatch work? You might be right, I just want to understand the problem more. For example take a quantum time evolution operator exp(-I*t*H). What if I wanted to develop custom logic for that operator. Simply matching on type type (exp) won't work. You need to be able to say: exp(-I*Numer(x_)*HermitianOperator(y_)) That requires pattern matching... To answer Aaron's question: On Wed, Jul 3, 2013 at 12:58 PM, Aaron Meurer asmeu...@gmail.com wrote: So, going back to what we discussed the first time we met in Los Alamos, how would you reimplement something like the oo logic so that it lives entirely in the Infinity class, not in Add.flatten (say for simplicity, oo + 3 should go to oo, but oo + 3*I should remain as oo + 3*I)? This, and another example is x + O(x). Let's stick to oo + 3. This is a very good question and it is one of the details that I don't know the answer 100% yet. But I feel it is solvable. The general idea is that you create a new type, let's say Infinity and register mul, add, div, sub, pow using dispatch, which specify how your new type should be handled. In particular, it would look something like: @dispatch(Infinity, Basic) def mul(a, b): if isinstance(b, Integer): return a else: return Add(a, b) But Mul is not a binary operator in SymPy - we could make it so and build the overall *args version by repeatedly calling the binary version. That would be nice... and would somewhat help our situation... This covers most usecases for oo, since when you construct it in Python, you always use the two argument mul(a, b). Also when Add is constructed, the algorithm simply takes one term at a time and adds it to what is in Add already. So those are all binary operations that could be overridden in principle. For example a faster core might decide for speed reasons to not allow oo and O(x) terms. Then multiple dispatch would pretty much make sure that either the fast core will be used if you do add(x, y), but slow and more general sympy core will be used if you do add(x, oo). I think the best would be to create a demo (from scratch) where we can play with these ideas. Hopefully I'll get to this eventually. Ondrej Cheers, Brian On Wednesday, July 3, 2013 10:27:19 AM UTC-7, Aaron Meurer wrote: No, Add(x, y, z, t) is not just used for fast construction. Any algorithm that recurses through an expression tree and rebuilds things will rebuild an Add in that way, using expr.func(*expr.args). Aaron Meurer On Wed, Jul 3, 2013 at 12:22 PM, Ondřej Čertík ondrej...@gmail.com wrote: On Wed, Jul 3, 2013 at 11:15 AM, Aaron Meurer asme...@gmail.com wrote: I don't think it's so easy, because Add has *args. If you are talking about things like: In [2]: Add(x, x, x, y, x, x) Out[2]: 5⋅x + y Then those are of course needed
Re: [sympy] Multiple dispatch in SymPy
On Wed, Jul 3, 2013 at 2:42 PM, Ondřej Čertík ondrej.cer...@gmail.com wrote: On Wed, Jul 3, 2013 at 3:19 PM, Brian Granger elliso...@gmail.com wrote: On Wed, Jul 3, 2013 at 1:42 PM, Ondřej Čertík ondrej.cer...@gmail.com wrote: On Wed, Jul 3, 2013 at 1:48 PM, Aaron Meurer asmeu...@gmail.com wrote: Brian, I think you dropped off list. Forwarding to sympy. Aaron Meurer On Wed, Jul 3, 2013 at 2:29 PM, Brian Granger elliso...@gmail.com wrote: I think that having multiple dispatch is something that is needed within SymPy. Multiple people have run into the difficulties with providing custom Add/Mul logic for their new types. In quantum, we just punted and used the builtin Add/Mul logic, but it was a bad compromise to make. For this, I think looking at Mathematica is really important. This is handled by Mathematica's Rules and Patterns which are documented here: http://reference.wolfram.com/mathematica/guide/RulesAndPatterns.html http://reference.wolfram.com/mathematica/tutorial/Introduction-Patterns.html If we don't have first class, nested and general pattern matching, we can't do multiple dispatch. The case in point is classes that accept *args such as Add and Mul. Good fast pattern matching would also allow us to do much of the logic in Add/Mul constructors using patterns: Add(x_, x_) - 2*x_ Mul(x_, x_) - x**2 Pattern matching is another way to implement CAS, but I am actually not sure this is how Mathematica works inside. Also in pure Python, this might be really slow (I don't know). I don't see all the little details for pattern matching approach. I think I can see more of the details for the sympy approach though. etc. Summary - simple type based dispatch won't do - we need full blown pattern matching and transformation logic. Why wouldn't simple type based dispatch work? You might be right, I just want to understand the problem more. For example take a quantum time evolution operator exp(-I*t*H). What if I wanted to develop custom logic for that operator. Simply matching on type type (exp) won't work. You need to be able to say: exp(-I*Numer(x_)*HermitianOperator(y_)) That requires pattern matching... So first of all, since H does not commute, H will not be a Symbol, but rather an NCSymbol. Then the * in there will not be Mul but NCMul, thanks to our binary dispatch. exp can in principle be NCFunction or something. But that is besides the point - there are infinitely other examples where you need to apply pattern matching logic that is not merely type based. What kind of custom logic are you thinking of? The automatic canonical simplification should only be very simple things, most probably in this case just things that NCMul can do. I am thinking that the automatic canonical simplification logic everywhere in sympy would be replaced by rules+patterns. Anything more advanced (like perturbation expansion of exp) should be implemented as an extra function. I completely agree... To answer Aaron's question: On Wed, Jul 3, 2013 at 12:58 PM, Aaron Meurer asmeu...@gmail.com wrote: So, going back to what we discussed the first time we met in Los Alamos, how would you reimplement something like the oo logic so that it lives entirely in the Infinity class, not in Add.flatten (say for simplicity, oo + 3 should go to oo, but oo + 3*I should remain as oo + 3*I)? This, and another example is x + O(x). Let's stick to oo + 3. This is a very good question and it is one of the details that I don't know the answer 100% yet. But I feel it is solvable. The general idea is that you create a new type, let's say Infinity and register mul, add, div, sub, pow using dispatch, which specify how your new type should be handled. In particular, it would look something like: @dispatch(Infinity, Basic) def mul(a, b): if isinstance(b, Integer): return a else: return Add(a, b) But Mul is not a binary operator in SymPy - we could make it so and build the overall *args version by repeatedly calling the binary version. That would be nice... and would somewhat help our situation... Roughly that's how it works internally, that you take each term and try to apply/combine it with all the previous ones. The actual implementation in sympy has gotten quite complicated over the years. 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 sympy+unsubscr...@googlegroups.com. To post to this group, send email to sympy@googlegroups.com. Visit this group at http://groups.google.com/group/sympy. For more options, visit https://groups.google.com/groups/opt_out. -- Brian E. Granger Cal Poly State University, San Luis Obispo bgran...@calpoly.edu and elliso...@gmail.com -- You received this message because you are subscribed to the Google Groups sympy group
Re: [sympy] Feynman diagrams
Extra bonus points if this stuff can be integrated with sympy.physics or even better sympy.physics.quantum...otherwise we just keep creating new corners of sympy that don't work together. I know it is easier, but in the long run it is a horrible situation. The stuff in sympy.physics.quantum is completely general and should be able to handle all of this with some work. It would also be great to get secondquant.py into sympy.physics.quantum so it doesn't reinvent the wheel. It even has wicks theorem, which is the foundation of all Feynman diagrams. Let's do this right! Cheers, Brian On Sun, Jun 30, 2013 at 10:38 AM, Ondřej Čertík ondrej.cer...@gmail.com wrote: Hi Stefan, This is cool. I would be interested in having this in sympy. Long time ago I wrote some diagram generating code for scalar diagrams: https://github.com/certik/sympy/blob/wick/t.py but I didn't have time to polish it up and send a PR. As you correctly mentioned, there are lots of steps and actually several approaches to this problem and we should simply start adding such codes to sympy. What I wrote is just one little tiny bit, but it is still useful to check scalar particle diagrams. This is for relativistic theory. Then I have code here that generates the non-relativistic perturbation theory diagrams for total energy: https://github.com/certik/hfsolver/blob/master/src/diagrams_mbpt.py here is the corresponding Fortran code for evaluating them: https://github.com/certik/hfsolver/blob/master/src/mbpt.f90 these 3 files are generated: https://github.com/certik/hfsolver/blob/master/src/mbpt2.f90 https://github.com/certik/hfsolver/blob/master/src/mbpt3.f90 https://github.com/certik/hfsolver/blob/master/src/mbpt4.f90 and then the same for Green's functions: https://github.com/certik/hfsolver/blob/master/src/diagrams_gf.py and the Fortran code (this one I wrote by hand): https://github.com/certik/hfsolver/blob/master/src/gf2.f90 Anyway, we should have this in sympy. 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 sympy+unsubscr...@googlegroups.com. To post to this group, send email to sympy@googlegroups.com. Visit this group at http://groups.google.com/group/sympy. For more options, visit https://groups.google.com/groups/opt_out. -- Brian E. Granger Cal Poly State University, San Luis Obispo bgran...@calpoly.edu and elliso...@gmail.com -- 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 sympy+unsubscr...@googlegroups.com. To post to this group, send email to sympy@googlegroups.com. Visit this group at http://groups.google.com/group/sympy. For more options, visit https://groups.google.com/groups/opt_out.
Re: [sympy] Feynman diagrams
I don't know the physics well enough to know from your pseudo code. sympy.physics.quantum knows about quantum mechanics though: * Operators, states (bras, kets), commutators, anticommutators, outer projects, tensor projects, inner projects * The representation of those entities in different bases This stuff is done in completely generality, so you could define field operators that obey the right commutator/anticommutator relationships and then start computing commutators and expectation values needed for perturbation theory. I imagine that your expression above is further down the chain after various steps have been done in the perturbation theory. At that point, you are just dealing with functions, derivative, matrices = one particular representation of the theory. This has always been my complaint about high energy theory - it is developed in a way that makes it difficult to see that it is just regular old quantum mechanics... But the important question are these: * What types of physics objects are gluon? Operator? State? Representation of such in a particular basis? * What types of objects are group_generator? ... Cheers, Brian On Sun, Jun 30, 2013 at 2:35 PM, Stefan Krastanov krastanov.ste...@gmail.com wrote: @Brian, what would be the correct way to write something like gluon(lorentz_index, su3_index) * group_generator(su3_index, antispinor_index, spinor_index) * top_quark(spinor_index) in the physics.quantum module? On 30 June 2013 21:31, Brian Granger elliso...@gmail.com wrote: Extra bonus points if this stuff can be integrated with sympy.physics or even better sympy.physics.quantum...otherwise we just keep creating new corners of sympy that don't work together. I know it is easier, but in the long run it is a horrible situation. The stuff in sympy.physics.quantum is completely general and should be able to handle all of this with some work. It would also be great to get secondquant.py into sympy.physics.quantum so it doesn't reinvent the wheel. It even has wicks theorem, which is the foundation of all Feynman diagrams. Let's do this right! Cheers, Brian On Sun, Jun 30, 2013 at 10:38 AM, Ondřej Čertík ondrej.cer...@gmail.com wrote: Hi Stefan, This is cool. I would be interested in having this in sympy. Long time ago I wrote some diagram generating code for scalar diagrams: https://github.com/certik/sympy/blob/wick/t.py but I didn't have time to polish it up and send a PR. As you correctly mentioned, there are lots of steps and actually several approaches to this problem and we should simply start adding such codes to sympy. What I wrote is just one little tiny bit, but it is still useful to check scalar particle diagrams. This is for relativistic theory. Then I have code here that generates the non-relativistic perturbation theory diagrams for total energy: https://github.com/certik/hfsolver/blob/master/src/diagrams_mbpt.py here is the corresponding Fortran code for evaluating them: https://github.com/certik/hfsolver/blob/master/src/mbpt.f90 these 3 files are generated: https://github.com/certik/hfsolver/blob/master/src/mbpt2.f90 https://github.com/certik/hfsolver/blob/master/src/mbpt3.f90 https://github.com/certik/hfsolver/blob/master/src/mbpt4.f90 and then the same for Green's functions: https://github.com/certik/hfsolver/blob/master/src/diagrams_gf.py and the Fortran code (this one I wrote by hand): https://github.com/certik/hfsolver/blob/master/src/gf2.f90 Anyway, we should have this in sympy. 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 sympy+unsubscr...@googlegroups.com. To post to this group, send email to sympy@googlegroups.com. Visit this group at http://groups.google.com/group/sympy. For more options, visit https://groups.google.com/groups/opt_out. -- Brian E. Granger Cal Poly State University, San Luis Obispo bgran...@calpoly.edu and elliso...@gmail.com -- 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 sympy+unsubscr...@googlegroups.com. To post to this group, send email to sympy@googlegroups.com. Visit this group at http://groups.google.com/group/sympy. For more options, visit https://groups.google.com/groups/opt_out. -- 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 sympy+unsubscr...@googlegroups.com. To post to this group, send email to sympy@googlegroups.com. Visit this group at http://groups.google.com/group/sympy. For more options, visit https://groups.google.com/groups/opt_out. -- Brian E. Granger Cal Poly State University, San Luis Obispo bgran...@calpoly.edu and elliso
Re: [sympy] naive D3.js backend for our plotting module
Hi, we won't get a `_repr_vega_json` but what we will get is the ability of `_repr_json` to specify an appropriate handler on the JavaScript side of things. That handler would be where all of the custom JS code for vega would live. On Fri, May 17, 2013 at 1:22 PM, Stefan Krastanov krastanov.ste...@gmail.com wrote: I went ahead and implemented a simple clean version of d3/vega backend. It works ok, but it would be great if IPython gets something like `_repr_vega_json_`, because the `publish_javascript` method seems very hackish. Here is the pull request: https://github.com/sympy/sympy/pull/2120 On 15 May 2013 04:47, Brian Granger elliso...@gmail.com wrote: Once the IPython notebook gets a better architecture for interactive javascript capabilities (this work is planned during the 2nd half of 2013) I am expecting d3 based IPython work to explode. I am hopeful that there will be multiple notebook compatible d3 plotting libraries to choose from... Cheers, Brian On Tue, May 14, 2013 at 3:44 PM, Aaron Meurer asmeu...@gmail.com wrote: I'm sure David Li will be open to collaboration on this front. Aaron Meurer On Tue, May 14, 2013 at 4:06 PM, Stefan Krastanov krastanov.ste...@gmail.com wrote: If it is in SymPy we would be able to plot any expressions, not only those function that are in the javascript standard library. And I guess that with some ajax magic (which seems to be already employed), we would be able to separate the query into multiple python executions. And we wont need to reimplement the adaptive sampling or any other tweak present in the plotting module. So I believe it makes sense to have a D3 backend for the plotting module and to use it for sympy gamma. However, if I am the one that writes it, I probably will not be able to reuse the gamma code, simply because it is easier to start from scratch given the differences between the plotting in gamma and the plotting module in sympy (and my lack of knowledge on sympy gamma). -- 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 sympy+unsubscr...@googlegroups.com. To post to this group, send email to sympy@googlegroups.com. Visit this group at http://groups.google.com/group/sympy?hl=en-US. For more options, visit https://groups.google.com/groups/opt_out. -- 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 sympy+unsubscr...@googlegroups.com. To post to this group, send email to sympy@googlegroups.com. Visit this group at http://groups.google.com/group/sympy?hl=en-US. For more options, visit https://groups.google.com/groups/opt_out. -- Brian E. Granger Cal Poly State University, San Luis Obispo bgran...@calpoly.edu and elliso...@gmail.com -- 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 sympy+unsubscr...@googlegroups.com. To post to this group, send email to sympy@googlegroups.com. Visit this group at http://groups.google.com/group/sympy?hl=en-US. For more options, visit https://groups.google.com/groups/opt_out. -- 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 sympy+unsubscr...@googlegroups.com. To post to this group, send email to sympy@googlegroups.com. Visit this group at http://groups.google.com/group/sympy?hl=en-US. For more options, visit https://groups.google.com/groups/opt_out. -- Brian E. Granger Cal Poly State University, San Luis Obispo bgran...@calpoly.edu and elliso...@gmail.com -- 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 sympy+unsubscr...@googlegroups.com. To post to this group, send email to sympy@googlegroups.com. Visit this group at http://groups.google.com/group/sympy?hl=en-US. For more options, visit https://groups.google.com/groups/opt_out.
Re: [sympy] naive D3.js backend for our plotting module
Once the IPython notebook gets a better architecture for interactive javascript capabilities (this work is planned during the 2nd half of 2013) I am expecting d3 based IPython work to explode. I am hopeful that there will be multiple notebook compatible d3 plotting libraries to choose from... Cheers, Brian On Tue, May 14, 2013 at 3:44 PM, Aaron Meurer asmeu...@gmail.com wrote: I'm sure David Li will be open to collaboration on this front. Aaron Meurer On Tue, May 14, 2013 at 4:06 PM, Stefan Krastanov krastanov.ste...@gmail.com wrote: If it is in SymPy we would be able to plot any expressions, not only those function that are in the javascript standard library. And I guess that with some ajax magic (which seems to be already employed), we would be able to separate the query into multiple python executions. And we wont need to reimplement the adaptive sampling or any other tweak present in the plotting module. So I believe it makes sense to have a D3 backend for the plotting module and to use it for sympy gamma. However, if I am the one that writes it, I probably will not be able to reuse the gamma code, simply because it is easier to start from scratch given the differences between the plotting in gamma and the plotting module in sympy (and my lack of knowledge on sympy gamma). -- 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 sympy+unsubscr...@googlegroups.com. To post to this group, send email to sympy@googlegroups.com. Visit this group at http://groups.google.com/group/sympy?hl=en-US. For more options, visit https://groups.google.com/groups/opt_out. -- 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 sympy+unsubscr...@googlegroups.com. To post to this group, send email to sympy@googlegroups.com. Visit this group at http://groups.google.com/group/sympy?hl=en-US. For more options, visit https://groups.google.com/groups/opt_out. -- Brian E. Granger Cal Poly State University, San Luis Obispo bgran...@calpoly.edu and elliso...@gmail.com -- 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 sympy+unsubscr...@googlegroups.com. To post to this group, send email to sympy@googlegroups.com. Visit this group at http://groups.google.com/group/sympy?hl=en-US. For more options, visit https://groups.google.com/groups/opt_out.
Re: [sympy] Symbolic representation of sequences series
I agree with Aaron on this one. On Thu, May 9, 2013 at 11:10 PM, Aaron Meurer asmeu...@gmail.com wrote: What's wrong with Sum. The only issue I can see is that Sum represents some kind of algebraic antidifference operator (see the discussion at https://github.com/sympy/sympy/pull/1696 for example), whereas a series is a mathematical summation. There are also subtle differences in the latter if we consider only formal series or if we care about convergence conditions. But I don't see why Fourier series would be a separate class from, say, Taylor series. Do you want to store information about where the object came from? Aaron Meurer On Thu, May 9, 2013 at 6:59 PM, hacm...@gmail.com wrote: I think that a lot of interesting objects in mathematics are representable by some kind of series: power series, Fourier series (including orthogonal bases other than complex exponentials), and series representations of constants (e.g., many different ways of representing pi as a series). Solutions to ordinary and partial differential equations are often best (or only) given as series. In many cases, there is no simple formula for the terms in the series, but in many cases there is (and in some cases, there are several). When the functions are unfamiliar, the symbolic representation can give strong insight into the function. And in the case where no formula is available, one can often find asymptotic expressions that are close enough to give very accurate results. The question I have now is that if one were to implement the series mentioned above (power, Fourier, numerical) as classes, would one suffice or would each need a special implementation? It sees as if one class could represent all of them with two internal data members: nth coefficient and nth function. The nth function would be x**n, exp(i n x), and 1, respectively, for the different types series. I'm not sue if there is enough overlap to make this method of implementation make sense, but it is the first thing that comes to mind. As for products of functions, the terms of their series is a convolution of the terms of the individual series. On Thursday, May 9, 2013 6:52:21 PM UTC-4, Aaron Meurer wrote: So, algorithmically, what are our hopes of getting something like sin(x)*exp(x) to work? Can a hyper/meijerg-based algorithm ever hope to work? If we implement formulas for the nth derivative, and also the series multiplication formula, what are the chances of a summation algorithm getting a closed form for the inner sum in the multiplication formula? If hyper/miejerg could work, can we also get convergence conditions? For this particular example, we could get it pretty easily by rewriting the sin using complex exponentials first, but that trick obviously won't always work. It might be a worthy heuristic if getting the product of functions to work is otherwise hairy. For rational functions, there are nice polynomial algorithms to compute arbitrary terms in the series expansion (laurent or taylor). I'll have to check if they can be adapted to give a general term. Aaron Meurer On Thu, May 9, 2013 at 4:41 PM, someone some...@bluewin.ch wrote: (hyper([], [], x) == exp(x)). But I'm not sure what the function to go from exp(x) to hyper is. For going this way, I implemented the rewrite(hyper) on some of the newer special functions. But it's supported only on a very few functions yet. -- 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 sympy+un...@googlegroups.com. To post to this group, send email to sy...@googlegroups.com. Visit this group at http://groups.google.com/group/sympy?hl=en-US. For more options, visit https://groups.google.com/groups/opt_out. -- 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 sympy+unsubscr...@googlegroups.com. To post to this group, send email to sympy@googlegroups.com. Visit this group at http://groups.google.com/group/sympy?hl=en-US. For more options, visit https://groups.google.com/groups/opt_out. -- 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 sympy+unsubscr...@googlegroups.com. To post to this group, send email to sympy@googlegroups.com. Visit this group at http://groups.google.com/group/sympy?hl=en-US. For more options, visit https://groups.google.com/groups/opt_out. -- Brian E. Granger Cal Poly State University, San Luis Obispo bgran...@calpoly.edu and elliso...@gmail.com -- 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
Re: [sympy] General strategy for removing old assumptions
I am strongly -1 on having the new assumption logic in master but disabled globally with flags. On Wed, Apr 10, 2013 at 9:20 AM, Matthew Rocklin mrock...@gmail.com wrote: I think you would traverse the input expression tree once to collect all assumptions stored in that tree into a set. You would then use that set during the computation (maybe this goes into ask?). Probably a tree would cache its set of assumptions after the first traversal. In what case would facts change during a computation/query? It doesn't strike me as the slow part of assumptions. In any case it's something that you could slowly remove as code developed - fewer and fewer bits of code would depend on the assumptions field. But I don't like this idea anyway. I mostly don't like the idea of adding an extra field to Basic. It makes it substantially less basic. On Wed, Apr 10, 2013 at 11:01 AM, Tom Bachmann e_mc...@web.de wrote: On 10.04.2013 16:56, Matthew Rocklin wrote: Old and new assumptions differ in a few ways. 1. They store assumptions in different places (this is the main issue here I think) 2. They represent assumptions differently 3. They represent relations differently 4. They infer/compute differently I don't particularly like this idea, but one could consider a solution that changes 2,3,4 but doesn't change 1. Alongside the .args tuple, Basic could also hold an .assumptions frozenset as a field. Computations that use assumptions could then check both the global collection and all assumptions in the expression tree. This might be an intermediate step in our development. I thought about that, but it is not obvious how to make it work. I suppose you would need to take the transitive closure of all assumptions. I.e.: - take all facts, extract all symbols into a list L -0append the symbols in the expression being queried to L -for every object in L, read out the assumptions frozenset, and append it to facts - start over if the facts have changed This seems potentially quite slow. -- 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 sympy+unsubscr...@googlegroups.com. To post to this group, send email to sympy@googlegroups.com. Visit this group at http://groups.google.com/group/sympy?hl=en-US. For more options, visit https://groups.google.com/groups/opt_out. -- 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 sympy+unsubscr...@googlegroups.com. To post to this group, send email to sympy@googlegroups.com. Visit this group at http://groups.google.com/group/sympy?hl=en-US. For more options, visit https://groups.google.com/groups/opt_out. -- Brian E. Granger Cal Poly State University, San Luis Obispo bgran...@calpoly.edu and elliso...@gmail.com -- 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 sympy+unsubscr...@googlegroups.com. To post to this group, send email to sympy@googlegroups.com. Visit this group at http://groups.google.com/group/sympy?hl=en-US. For more options, visit https://groups.google.com/groups/opt_out.
Re: [sympy] GSOC 2013
Amit, Hi, welcome to SymPy! 2.Quantum Mechanics module : (i) Adding more features to spin section (Sean Vig has given a lead on this and I am working my way out on what can be done).(Will come out with some ideas by the end of the month) OK great, Sean is definitely the person to work with on the spin stuff. He would know exactly what needs to be done. (ii) From the ideas page I find three topics interesting but have to work on this to get the understanding of what is going on Dirac Delta Notation, position and momentum basis (I have tried to understand the code in the pull request) symbolic quantum computing. The dirac notation stuff is basically done. But the position and momentum stuff needs a lot of work. There was a bunch of work done previously and there is an open pull request that has some additional work. This is an important part of the code base, but just a warning: it is extremely difficult and you will have to have a very good understanding of quantum mechanics (probably at the graduate level or close to it) and know python well. If you are interested in this I would just start to dig into the code and the open pull request on the topic and see what you think needs to be done. Even the tensor module sounds pretty interesting but my understanding would be not be that mathematical as I have just used them in physics (I can work upon on it). Coming to the background I have in the subject I have been doing a course on Integral transforms back at the university and have done a course in quantum computation and have been guided by the professors in the area of Quantum Physics.I know this is very much not in place but I would work on the Quantum Physics part and would move through the code and figure out how it has to be done.I would like to know your view on this topic as there would be medium work done to both the modules (would like to know the take on the first one and is it possible to squeeze a project by contributing evenly to two modules rather than one (since neither both ideas would stand alone as a single long project).Thanks. There is additional work to be done on the quantum computing stuff: * Quantum error correction * Quantum circuit simplification/optimization * Better circuit drawing * Use numba/cython/julia to generate fast code for simulating quantum circuits. Hope this gives you an idea of where to start. Cheers, Brian -- 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 sympy+unsubscr...@googlegroups.com. To post to this group, send email to sympy@googlegroups.com. Visit this group at http://groups.google.com/group/sympy?hl=en. For more options, visit https://groups.google.com/groups/opt_out. -- Brian E. Granger Cal Poly State University, San Luis Obispo bgran...@calpoly.edu and elliso...@gmail.com -- 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 sympy+unsubscr...@googlegroups.com. To post to this group, send email to sympy@googlegroups.com. Visit this group at http://groups.google.com/group/sympy?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Re: [sympy] GSoC 2013 Idea(s):Optimization/ Graph Theory
A number of people have asked about graph theory in sympy in the past. Our feeling is that with the high quality of NetworkX, it doesn't make sense to reinvent graph theory in sympy. Maybe talk to the NetworkX folks about doing a GSoC with them? On Mon, Mar 18, 2013 at 2:06 AM, Rajat Kapoor rajat100...@gmail.com wrote: About me Hi, my name is Rajat Kapoor and I'm currently pursuing Engg. in Electrical and Electronics along with M.S. in Mathematics in BITS Pilani Goa. I'm from India, and have sheer interest in computer programming as well as Mathematics. Few of my favorite areas in Mathematics include Optimization Techniques and Graph Theory Contact: rajat100...@gmail.com , rajat100493(skype), rajatkapoor(github) Programming Skills I've done coding in several high-level languages (C, C++,Java, C#, Python). My most preferred among all these is C#, mostly because of the powerful IDE options available but when it comes to cross platform development, I prefer Python because of its simplicity. I have completed a few intermediate level virtual courses in Python at college and have had guidance from a helpful lot of seniors with regard to a few informal projects in python. Apart from this I have amateur programming skills in web technologies including HTML, CSS, XML, PHP. Other areas of interest include Image Processing(using SimpleCV and OpenCV). I also have a very basic knowledge of GUI based programming in Java as well as python(using PyQt and wxWidgets). I have a negligible experience with git but I've learnt the concept well and have started using it lately. Project Idea: Becasue of my avid interest in the above mentioned areas I propose the idea of working on ONE of the following projects, which seems viable as well as pretty apt to be merged into sympy Addition of a new Optimization module OR Addition of Graph Theory Module Though my peak interest is in developing the above mentioned modules, but due to its strong dependencies on the matrices module, I'll have to add some more functionality to the matrices module. Optimization Module: Features of the optimization module: Solving to linear programming problems from the given matrix or polynomial input: Simplex algorithms along with a few variations(M-method, Two Phase, Dual Simplex, and Generalised Simplex methods) will be used to solve such problems Recognition of special cases(degeneracy, alternative optima, unboundedness, infeasability) Transformation into dual problems: using primal dual relations Post optimal analysis: how feasibility and optimality are affected Transportation model solving: Starting solution to be obtained via northwest corner method/ least cost method/vogel approximation method then proceeding towards optimality using simplex iterations Assignment model solving: using Hungarian method. Any other ideas relating to the optimization field will also be added Graph Theory Module(which i personally prefer more): Input of graphs will be taken in form of adjacency list/adjacency matrix/ incidence matrix. Interconversion between these three forms will be provided.This module will initially aim to provide the following functionality: Manipulation with degree of vertices, including detection of cut vertices, formation of line graphs, finding closure, eccentricity,girth of a graph Simple graph operations like join, subtract, union, etc will be added Isomorphic graph detection will be implemented, by using some of the functions in the already existing matrices module. Extra functions required will be added to the matrices module itself. Functionality relating to the regularity as well as planarity(Tarjan's algorithm) of graphs will also be added. Cycles: number of cycles and the cycles itself will be found out. Detection of cycles in the graph will be done using Tarjan's algorithm or any other algorithm that can be implemented with ease. Trees: all functions regarding no of nodes, root node, nodes at seperate levels, etc. Trees will be recognized by cycle detection process. Minimum spanning tree finding functionality will be added using Krusal's or Prim's algorithm. Hamiltonian graphs: methods of detection will be implemented using Dirac's, Ore's definition or Bondy-Chvátal theorem or by finding a cut vertex. Eulerian graphs : Checking the “even-ness” of degree of all vertices. Fleury algorothm (implemented using Tarjan's algorithm to detect bridges) or Hierholzer's algorithm to find the eulerian cycle. Special classes of graphs viz. Complete graphs, bipartite graphs, multipartite graphs and hypercubes will also be pre-defined I have a very clear idea on how to implement the ideas stated above. These functions will be first implemented for simple, undirected graphs and then will be extended to multigraphs, directed graphs in due course of time. Moreover, other suggested functionality will also be added. Main Question: Please give me
Re: [sympy] Graph Theory
I think the standard answer is that NetworkX already has amazing graph theory capabilities and it would be silly to reinvent all of that stuff in SymPy. It is not even clear how the symbolic capabilities of SymPy are even relevant in graph theory. On Wed, Feb 20, 2013 at 10:40 PM, Sachin Joglekar srjoglekar...@gmail.com wrote: On this link - http://en.wikipedia.org/wiki/List_of_computer_algebra_systems One of the featues which SymPy has a 'no' for is that of Graph Theory. Could we implement it for SymPy? I have a fair amount of knowledge about Graph Theory and learning more as a part of my coursework.And as it is, I am planning to put in a proposal for SymPy for GSOC. Can it be a project idea I may work on? -- 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 sympy+unsubscr...@googlegroups.com. To post to this group, send email to sympy@googlegroups.com. Visit this group at http://groups.google.com/group/sympy?hl=en. For more options, visit https://groups.google.com/groups/opt_out. -- Brian E. Granger Cal Poly State University, San Luis Obispo bgran...@calpoly.edu and elliso...@gmail.com -- 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 sympy+unsubscr...@googlegroups.com. To post to this group, send email to sympy@googlegroups.com. Visit this group at http://groups.google.com/group/sympy?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Re: [sympy] rewrite rules, canonicalization and autoevaluation
In my mind in sympy we are using the following guidelines to determine what
gets done at object construction:
* By default only do evaluations/simplifications that everyone will always
want.
* Rely on methods like, expand, rewrite, doit, etc. to actually trigger
additional simplifications/evaluations.
I would much prefer this to us starting to create multiple implementations
of everything.
On Fri, Nov 2, 2012 at 11:54 AM, Aaron Meurer asmeu...@gmail.com wrote:
I think we are going to constantly have this battle between things being
unevaluated and evaluating them (at construction time) as long as we try to
do both with the same class. It's a similar issue as
http://code.google.com/p/sympy/issues/detail?id=1887. If you are
conflicted between wanting something to do two things, instead of arguing
about which it should do, maybe the best solution is to just make two
classes. In this case, it means that we need a user-level class Trace that
does the autosimplification at construction time, and another class that
represents an unevaluated trace that you can use to build your unification
rules, or as intermediaries of matrix transformation rules, or whatever.
This is the same thing as I was saying in the rules PR about need two
classes (https://github.com/sympy/sympy/pull/1560#issuecomment-9640562,
and also the next two comments).
Of course, you could also try to represent things just using Symbols.
This is like my original suggestion of an identity rule that represents
sin(x)**2 + cos(x)**2 = 1 as the equation with Symbols s**2 + c**2 = 1 and
the mapping {s:sin, c:cos}. Creating unevaluated classes may be cleaner in
the long run, but trying to do it with the classes without creating
unevaluated versions will just be a constant battle and will never work.
Aaron Meurer
On Fri, Nov 2, 2012 at 9:51 AM, Stefan Krastanov
krastanov.ste...@gmail.com wrote:
Given the comments of both of you I propose the following addition
(isolated to the rules module in order not to cause too much arguing):
- adding a gather_rules function that traverses the tree and checks
for any rules registered with the objects. For instance
my_very_special_matrix object will have the following property
my_very_special_matrix.rules_register = {'simplify':
[the_rule_square_is_identity,]}
and trace will have
Trace.rules_register = {'canonicalize': [trace_unpack_scalar, ]}
This will be slow, but it will permit great freedom. We can optimize it
later.
It will also work with the ugly idea that I had about calling all the
constructors.
ClassUnsupportedByRules.rule_register = {'canonicalize':
[call_the_constructor, ]}
On 2 November 2012 16:42, Stefan Krastanov krastanov.ste...@gmail.com
wrote:
How do you get Matrix = scalar?
very_special_matrix**2 is equal to scalar*Identity. The scalar is
(should be) factored out of the Trace.
points to consider:
1. I want to use only the following custom rule:
very_special_matrix_a**2 - scalar*Identity
Why is Trace not auto evaluated? I suppose you're creating it via
Basic__new__ rather than the Trace constructor? This is getting to the
issue that Ronan foresaw in the original pull request. Basic.__new__
seemed ok to me, but only to create the original object. Using it to
create new objects instead of their constructors is a bad idea.
The way that trace works is not based on canonicalization in the
constructor (or at least when it is fixed it wont be) hence my
disagreement with your comment and Ronan.
--
You received this message because you are subscribed to the Google Groups
sympy group.
To post to this group, send email to sympy@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.
--
You received this message because you are subscribed to the Google Groups
sympy group.
To post to this group, send email to sympy@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.
--
Brian E. Granger
Cal Poly State University, San Luis Obispo
bgran...@calpoly.edu and elliso...@gmail.com
--
You received this message because you are subscribed to the Google Groups
sympy group.
To post to this group, send email to sympy@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.
Re: [sympy] RFC - A plan for rewrite rules in SymPy
In general I am very much in favor of having more sophisticated expression transformation capabilities in SymPy. For something like rewrite rules I would love it if we can study what Mathematica does. Wolfram got that part right. On Thu, Oct 4, 2012 at 5:17 PM, Matthew Rocklin mrock...@gmail.com wrote: Hi Everyone, I'm planning to add a simplification system for sympy.matrices.expressions that is built on rewrite rules. I hope that this will be a nice test case for the feasibility of rewrite rules in the rest of SymPy. I would like to get feedback on design before I start work. First, rewrite rules are a way to transform an expression. This way tries to separate what happens from how it happens. We create rules like the following: def remove_ones(a_mul): Remove multiplicative identities from a Mul return Mul(*[arg for arg in a_mul.args if arg != 1]) These rules describe transformations that we might want to apply onto a node in our sympy expression. A rule is a function Expr - Expr We combine and arrange rules with strategies. Here are two strategies def conditional(condition, rule): Only apply rule if condition is true def new_rule(expr): if condition(expr): return rule(expr) else : return expr return new_rule def traverse_ast(rule): Apply a rule down a syntax tree traversing top-down def new_rule(expr): if expr.is_Atom: return rule(expr) else:return rule(expr.__class__(map(new_rule, expr.args))) return new_rule A strategy is generally a function [Rules] Other-stuff - Rule We might then create a rule to remove ones from all muls down a syntax tree as follows remove_all_ones = traverse_ast(conditional(lambda expr: expr.is_Mul, remove_ones)) These strategies and rules are generally built up in interesting ways. What's nice about this is the following 1. The strategies are reusable 2. The rules are reusable 3. The rules supply very clear intent - they are easy to reason about 4. Efficiency is separate from logic. What's bad about this is the following 1. It's probably slower than what we have now 2. It is a bit more sophisticated/clever. Requires you to think about higher order functions Again, my plan is to implement this for MatrixExpressions as a test case. I'm posting it here now in case people have suggestions/warnings/pointers. Best, -Matt -- You received this message because you are subscribed to the Google Groups sympy group. To post to this group, send email to sympy@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. -- Brian E. Granger Cal Poly State University, San Luis Obispo bgran...@calpoly.edu and elliso...@gmail.com -- You received this message because you are subscribed to the Google Groups sympy group. To post to this group, send email to sympy@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.
Re: [sympy] RFC - A plan for rewrite rules in SymPy
The Mathematica docs are all online and are some of the best docs I have ever seen: http://reference.wolfram.com/mathematica/guide/RulesAndPatterns.html The bottom of this page has some links to tutorials on this topic as well. On Thu, Oct 4, 2012 at 7:48 PM, Matthew Rocklin mrock...@gmail.com wrote: On Thu, Oct 4, 2012 at 9:33 PM, Brian Granger elliso...@gmail.com wrote: In general I am very much in favor of having more sophisticated expression transformation capabilities in SymPy. For something like rewrite rules I would love it if we can study what Mathematica does. Wolfram got that part right. I'm aware that Mathematica's core is a rewrite rule system. I'm not personally familiar with it. Can anyone suggest a good introductory material on how it works? -- You received this message because you are subscribed to the Google Groups sympy group. To post to this group, send email to sympy@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. -- Brian E. Granger Cal Poly State University, San Luis Obispo bgran...@calpoly.edu and elliso...@gmail.com -- You received this message because you are subscribed to the Google Groups sympy group. To post to this group, send email to sympy@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.
Re: [sympy] qapply on (number times operator otimes operator) (vector otimes vector)
This pull request definitely needs some attention. I don't have any
time to work on it right now, but it shouldn't be too difficult to
finish.
On Mon, Aug 27, 2012 at 10:35 AM, Uğur Güney ugurgu...@gmail.com wrote:
Dear Aaron,
Thanks for your help on automation! Because I've a big operator in the form:
c_1*projUV_1* + c_2*projUV_2 + ...
Now I can apply the Mul(*c)*qapply(tensor_product_simp(Mul(*nc))) on each
term in a loop. ^_^ I'll try it tonight. I think it would be better if
qapply handles this stuff by itself but the workaround is fine with me.
Have a good day!
vug
On Sat, Aug 25, 2012 at 2:29 PM, Aaron Meurer asmeu...@gmail.com wrote:
I'd say this is a bug. It looks like it's been fixed at
https://github.com/sympy/sympy/pull/1053. That PR seems to have been
stalled, so maybe you could see what needs to be done.
An obvious work-around is to pull out the 2 from the qapply:
In [19]: print 2*qapply(tensor_product_simp(projUV*vecUV)) # the
number stops the machinery
2*u1|u2*v1|v2*|u1x|v1
You can use args_cnc to help automate this:
In [22]: a = (2*projUV*vecUV)
In [24]: a.args_cnc()
Out[24]: [[2], [❘u₁⟩⟨u₁❘⨂ ❘v₁⟩⟨v₁❘, ❘u₂⟩⨂ ❘v₂⟩]]
In [26]: c, nc = a.args_cnc()
In [27]: Mul(*c)*qapply(tensor_product_simp(Mul(*nc)))
Out[27]: 2⋅⟨u₁❘u₂⟩⋅⟨v₁❘v₂⟩⋅❘u₁⟩⨂ ❘v₁⟩
(by the way, we should have an as_commutative_noncommutative method)
I guess that won't work if you need to do factorization, but there are
other methods that can help you there too (like factor_terms).
I hope someone who actually knows the quantum stuff will point it out
if something I said above is wrong.
Aaron Meurer
On Sat, Aug 25, 2012 at 9:13 AM, Uğur Güney ugurgu...@gmail.com wrote:
Hi All!
I am working on a research problem and wanted to use sympy's quantum
module
to do the calculations, because sympy has abstract Ket objects on which
one
can do many operations without assigning them actual values. I come up
with
a difficulty
Say I have two Hilbert spaces U and V and on each space I have two
vectors
from sympy import *
from sympy.physics.quantum import *
u1=Ket('u1')
u2=Ket('u2')
v1=Ket('v1')
v2=Ket('v2')
projU = u1*u1.dual # a projection operator on u1
print qapply(2*projU*u2) # qapply works as expected
projV = v1*v1.dual # an operator on V
projUV = TensorProduct(projU, projV) # operator on UV
vecUV = TensorProduct(u2,v2) # vector in UV
print qapply(tensor_product_simp(projUV*vecUV)) # works as expected
again
print qapply(tensor_product_simp(2*projUV*vecUV)) # the number stops the
machinery
outputs:
2*u1|u2*|u1
u1|u2*v1|v2*|u1x|v1
2*(|u1u1|*|u2)x(|v1v1|*|v2)
I'll be glad if you can tell me how I can qapply on expressions in the
form
x*projUV*vecUV.
Have a good day!
ugur
--
You received this message because you are subscribed to the Google
Groups
sympy group.
To post to this group, send email to sympy@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.
--
You received this message because you are subscribed to the Google Groups
sympy group.
To post to this group, send email to sympy@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.
--
You received this message because you are subscribed to the Google Groups
sympy group.
To post to this group, send email to sympy@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.
--
Brian E. Granger
Cal Poly State University, San Luis Obispo
bgran...@calpoly.edu and elliso...@gmail.com
--
You received this message because you are subscribed to the Google Groups
sympy group.
To post to this group, send email to sympy@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.
Re: [sympy] Location for Tr operation
Guru, Thanks for summarizing things and making a recommendation. I agree with your proposal. On Wed, Aug 1, 2012 at 9:33 AM, Guru Devanla grd...@gmail.com wrote: I went through the entire thread again, I feel we should just move the 1. Tr module into matrices/expressions 2. Decide between inheriting from Expr or MatExpr. I would let it inherit from MatExpr, but set is_Matrix = false, if indices = all_indices. 3. And *not* have 2 classes, since except for indices all other implementation details are same, and user gets cleaner API to deal with. Here is the summary of some points made and why I feel this way: 1. Tr == Partial trace on all indices. This just says the arguments of Tr behave differently during evaluation based on the implementation of _eval_args(). Even if we had 2 different classes(Tr, PartialTr), the implementations would be the same since we end up calling _eval_trace(). Every other implementation details of these 2 classes would be the same. Yes, because of this I strongly feel Tr and PartialTr should not be separate classes. 2. The current implementation though is used heavily by quantum module, still does not *depend* on quantum module. This just states that Tr is not *required* to reside in the physics/quantum folder. Yep. 3. Matthew suggested we could have 2 different classes and let Partial Trace yield a Tr object if indices == all_indices. But, looking from user API perspective this just complicates things. I was looking at the use cases when user would be creating these objects, and did not think we should force user to pick between Tr and PartialTr. It should just be Tr(args, [tuple of indices]). Again, another point for these being the same class. The one point Matthew made was regarding during evaluation Tr yields an Expr/Scalar whereas partial trace yields another matrix. But, is this point alone a good reason to split these classes, given all other implementation details are the same. I don't have a problem with this. If this becomes an issue in general matrix expressions, we can use the is_Matrix attribute to allow determination of its return value. Alternatively, if we decide to split these classes and place both of them in matrices/expressions. Then, I see that the PartialTr class does not have any specific functionality except to yield a Tr object in some cases. Apart from that, all other implementation details on Trace class applies to PartialTr. So, in summary I would move the Tr class to matrices/expressions and let in inherit from MatExpr. The user could always use Tr() class to run either trace or partial trace operation. During _eval_trace(), if the operation is a partial trace operation, then an appropriate object ( matrix ) is returned. Also, if indices = all_indices, we could set the is_Matrix = False. Yep. Or, if MatExpr does not apply to general case of Tr, then we should simple let Tr inherit from Expr. I am not sure if this inheritance heirarchy should stop Tr from being in the matrices/expressions folder. Thoughts? I am +1 on this. Brian -Guru On Thursday, July 12, 2012 5:34:22 PM UTC-5, Matthew wrote: Yes, the concept is quite subtle and not used (as far as I know) outside the context of quantum mechanics (where it is used a lot). I thought about having separate Trace and PartialTrace classes, but from the user API standpoint, they are really the same thing. Trace = Partial Trace over all indices The immediate issue I see if this goes into MatrixExprs is that PartialTrace is a MatExpr while Trace is an Expr/Scalar. It's not easy to have a class that is both at the same time. If we do this then my approach would be to make both classes and have PartialTrace(arg, indices) yield a new Trace object on object creation when indices == all_indices. However, if partial traces are rarely used outside of quantum then maybe it makes sense to just keep them in quantum. A lot of the code in Guru's PR doesn't seem to apply to the MatrixExpr case (namely the tensor product stuff). MatrixExpressions is pretty restricted to linear algebra and not multi-linear algebra. I'm inclined to keep it this way. I think that an attempt to generalize the current module will result in an ugly solution. I think that this stuff should probably live in quantum until we get around to a Tensor expressions module. I think that I should make a simple Trace for MatrixExpressions and that the more sophisticated partial-trace on tensor-products code should move from sympy/core to sympy/physics/quantum for now. -- Brian E. Granger Cal Poly State University, San Luis Obispo bgran...@calpoly.edu and elliso...@gmail.com -- You received this message because you are subscribed to the Google Groups sympy group. To post to this group, send email to sympy@googlegroups.com. To unsubscribe from this group, send email to
Re: [sympy] Location for Tr operation
Matthew, On Wed, Aug 1, 2012 at 10:47 AM, Matthew Rocklin mrock...@gmail.com wrote: I am still -1 on this. There is a larger discussion lurking here though. Right now, the vision of matrix expressions leaves out a huge class of operation involving matrices, namely those related to tensor products. Many operations on matrices naturally extend to tensor products of matrices and all of these things also extend to linear operators on Hilbert spaces. Other examples of things that can be defined on tensor products of matrices: Transpose, Adjoint. All of these operations have a similar API as Trace/Partial trace in that you can do the operation on all matrices in a tensor product, or just some of them (the partial version). I agree these operations are not common outside of quantum mechanics, but tensor products are a mainstream part of linear algebra. Are you open to the matrix expression modules gaining knowledge of tensor products? If not, we are going to have to reimplement everything in both matrix expressions and outside of it. BTW, we are already going in this direction, in the sense that we have a PR open #1158 for transpose/adjoint classes in sympy/functions/elementary/complexes.py. The quantum module is using those. Maybe this is the direction we need to go. In that case, why not put Trace in the same place as transpose/adjoint, as they are very similar. I have no problem to an unevaluated PartialTrace object living in matrix/expressions. I just think that it should be separate. Here are some of my concerns. From a user perspective having two separate classes is simpler in expectation. 99% of the time a user will want Trace. These users should not have to deal with the complexity of PartialTrace. I.e. the docstring for Trace should be very simple and intuitive. PartialTrace is foreign to most users. Unless a user is doing quantum mechanics, then they will want partial traces a good fraction of the time. I am still thinking about having separate trace and partial trace operations, but I want to come up with a unified way of handling these partial operations (for transpose/adjoint) as well. Not sure it makes sense to have partial transpose/adjoint as well. I am still leaning towards having a single object, but am considering the 2 object option as well. Trace is a scalar, PartialTrace can be a Matrix. The type system in the MatrixExpr module is much stricter than in physics/quantum. There is no way to have an object that is both. All MatrixExpr's have a shape. What is the shape of Trace(X)? If it is 1x1 then it will not be able to interact with other MatrixExprs. The MatrixExpr module is very clean and simple right now. I will strongly object to any type magic. The module is currently very simple, I would really like to keep it this way. I can see how this would be useful in matrix expressions if you don't ever plan on generalizing things to include tensor products. If you do though, these things will come up. I think that having two simple classes is far simpler than having one complex class that can be many things. But it is not really that complex and it is not many things, just two at most. Here is a PR for simple Trace. It is on top of another PR so only the last two commits are relevant to this conversation https://github.com/sympy/sympy/pull/1456 I guess the larger question is how you see matrix expressions co-existing with the rest of sympy. Is the stuff in matrix expressions so specialized that it is justified to have its own implementations of everything like trace/transpose/adjoint? Cheers, Brian -- You received this message because you are subscribed to the Google Groups sympy group. To post to this group, send email to sympy@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. -- Brian E. Granger Cal Poly State University, San Luis Obispo bgran...@calpoly.edu and elliso...@gmail.com -- You received this message because you are subscribed to the Google Groups sympy group. To post to this group, send email to sympy@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.
Re: [sympy] Location for Tr operation
On Wed, Aug 1, 2012 at 11:02 AM, Matthew Rocklin mrock...@gmail.com wrote: What about having a Trace(Expr) object, a PartialTrace(MatrixExpr) object (which must be strictly a partial trace, not a full one, I.e. indices can not equal all_indices) and a function that provides a general interface. That is a possibility, but I first want to understand the bigger picture of where things like this are going to live in sympy and if there will be duplication. I would be much happier with this. I would still push for 1) _eval_trace belongs to Trace, _eval_partial_trace would be created for whatever objects want to use it (stuff in quantum) 2) the interface function is not the default way in which people interact with Trace. It is an optional convenience function for those who want to sometimes use PartialTrace. In this setup it is obvious what type each class is. There is a unified interface for those who want to use indices= On Wed, Aug 1, 2012 at 12:47 PM, Matthew Rocklin mrock...@gmail.com wrote: I am still -1 on this. I have no problem to an unevaluated PartialTrace object living in matrix/expressions. I just think that it should be separate. Here are some of my concerns. From a user perspective having two separate classes is simpler in expectation. 99% of the time a user will want Trace. These users should not have to deal with the complexity of PartialTrace. I.e. the docstring for Trace should be very simple and intuitive. PartialTrace is foreign to most users. Trace is a scalar, PartialTrace can be a Matrix. The type system in the MatrixExpr module is much stricter than in physics/quantum. There is no way to have an object that is both. All MatrixExpr's have a shape. What is the shape of Trace(X)? If it is 1x1 then it will not be able to interact with other MatrixExprs. The MatrixExpr module is very clean and simple right now. I will strongly object to any type magic. The module is currently very simple, I would really like to keep it this way. I think that having two simple classes is far simpler than having one complex class that can be many things. Here is a PR for simple Trace. It is on top of another PR so only the last two commits are relevant to this conversation https://github.com/sympy/sympy/pull/1456 -- You received this message because you are subscribed to the Google Groups sympy group. To post to this group, send email to sympy@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. -- Brian E. Granger Cal Poly State University, San Luis Obispo bgran...@calpoly.edu and elliso...@gmail.com -- You received this message because you are subscribed to the Google Groups sympy group. To post to this group, send email to sympy@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.
Re: [sympy] Location for Tr operation
For matrices it looks like this: http://en.wikipedia.org/wiki/Kronecker_product Cheers, Brian On Wed, Aug 1, 2012 at 4:26 PM, Matthew Rocklin mrock...@gmail.com wrote: Can you define tensor product then? Are you referring to hadamard / elementwise product? On Aug 1, 2012 6:02 PM, Brian Granger elliso...@gmail.com wrote: On Wed, Aug 1, 2012 at 1:55 PM, Matthew Rocklin mrock...@gmail.com wrote: I'll reply more substantially in a bit (busy at work now) but I'll put in a quick word now. I think that an optimal version of SymPy would have a dedicated tensor module. I think that MatrixExpr would subclass TensorExpr. I should clarify something. The tensor product of matrices is itself a matrix, not a higher dimensional tensor. By TensorExpr, I think you are referring to something more general = a full blown tensor with rank potentially 2. Those types of tensors are not in any way relevant in quantum mechanics. Matrix expressions would inherit a lot from tensor expressions but I still think that they would need to be part of a separate submodule. Linear algebra has been developed much more than multilinear algebra and there are some thoughts and many use-cases that don't generalize. Again, multilinear algebra is not relevant here, just plain old linear algebra. I don't think that MatrixExprs should be generalized to TensorExprs. I think that TensorExprs should be created and then code from MatrixExprs factored out. I think this vision of having TensorExpr and MatrixExpr does make sense, but again, the types of operations under discussion here are under the matrix/linear algebra category. (I haven't mentioned anything here about the Tensor vs NDArray discussion, which is also relevant but complicates this idea) I'll take a look at your PR. Thanks for bringing it to my attention :) On Wed, Aug 1, 2012 at 2:23 PM, Brian Granger elliso...@gmail.com wrote: Matthew, On Wed, Aug 1, 2012 at 10:47 AM, Matthew Rocklin mrock...@gmail.com wrote: I am still -1 on this. There is a larger discussion lurking here though. Right now, the vision of matrix expressions leaves out a huge class of operation involving matrices, namely those related to tensor products. Many operations on matrices naturally extend to tensor products of matrices and all of these things also extend to linear operators on Hilbert spaces. Other examples of things that can be defined on tensor products of matrices: Transpose, Adjoint. All of these operations have a similar API as Trace/Partial trace in that you can do the operation on all matrices in a tensor product, or just some of them (the partial version). I agree these operations are not common outside of quantum mechanics, but tensor products are a mainstream part of linear algebra. Are you open to the matrix expression modules gaining knowledge of tensor products? If not, we are going to have to reimplement everything in both matrix expressions and outside of it. BTW, we are already going in this direction, in the sense that we have a PR open #1158 for transpose/adjoint classes in sympy/functions/elementary/complexes.py. The quantum module is using those. Maybe this is the direction we need to go. In that case, why not put Trace in the same place as transpose/adjoint, as they are very similar. I have no problem to an unevaluated PartialTrace object living in matrix/expressions. I just think that it should be separate. Here are some of my concerns. From a user perspective having two separate classes is simpler in expectation. 99% of the time a user will want Trace. These users should not have to deal with the complexity of PartialTrace. I.e. the docstring for Trace should be very simple and intuitive. PartialTrace is foreign to most users. Unless a user is doing quantum mechanics, then they will want partial traces a good fraction of the time. I am still thinking about having separate trace and partial trace operations, but I want to come up with a unified way of handling these partial operations (for transpose/adjoint) as well. Not sure it makes sense to have partial transpose/adjoint as well. I am still leaning towards having a single object, but am considering the 2 object option as well. Trace is a scalar, PartialTrace can be a Matrix. The type system in the MatrixExpr module is much stricter than in physics/quantum. There is no way to have an object that is both. All MatrixExpr's have a shape. What is the shape of Trace(X)? If it is 1x1 then it will not be able to interact with other MatrixExprs. The MatrixExpr module is very clean and simple right now. I will strongly object to any type magic. The module is currently very simple, I would really like to keep it this way. I can see how this would be useful in matrix expressions if you
Re: [sympy] adaptive sampling for plotting of surfaces
On Fri, Jul 20, 2012 at 2:54 AM, krastanov.ste...@gmail.com krastanov.ste...@gmail.com wrote: Just a quick suggestion if someone feels like doing it. There is a relatively new function in matplotlib that permits plotting triangular meshes. This is exactly the feature that was blocking the creation of adaptive sampling methods for the plotting module. If someone is interested to do it, you can get some inspiration from https://github.com/sympy/sympy/pull/1388 in which Bharath implemented a nice adaptive sampler for line plots. to plot the contour projection of the surface http://matplotlib.sourceforge.net/api/axes_api.html?highlight=contourf#matplotlib.axes.Axes.tricontourf 3d projections do not work yet At some point we should think about using Mayavi as a 3d backend. It is light-years ahead of matplotlib and what I would consider the standard solution for 3D plots in python But we should still offer matplotlib based 3D plotting -- You received this message because you are subscribed to the Google Groups sympy group. To post to this group, send email to sympy@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. -- Brian E. Granger Cal Poly State University, San Luis Obispo bgran...@calpoly.edu and elliso...@gmail.com -- You received this message because you are subscribed to the Google Groups sympy group. To post to this group, send email to sympy@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.
[sympy] Re: Suggestions for API fix in quantum module
On Wed, Jul 18, 2012 at 6:05 PM, Aaron Meurer asmeu...@gmail.com wrote: On Wed, Jul 18, 2012 at 6:40 PM, Brian Granger elliso...@gmail.com wrote: On Wed, Jul 18, 2012 at 12:13 PM, Aaron Meurer asmeu...@gmail.com wrote: In my branch where I'm fixing expand, I've moved the base _eval_expand functions to Expr. The result is that for expand to work on an object, it must be rebuildable via obj.func(*obj.args). There are two classes in the quantum module that came up where this doesn't work. One is OracleGate, which is built like OracleGate(2, lambda qubits: qubits == IntQubit(2)), which produces the .args ((0, 1), lambda qubits: qubits == IntQubit(2)) (in general, the first argument n is converted to range(n)). The second is WGate, which works like WGate(3), which produces the .args (2, 1, 0) (in general, an argument n produces reversed(range(n))). I was able to change OracleGate to accept its args without ambiguity. If the first argument is an integer, it does what it does now. If it's a tuple, succeed if it's of the form of range(N) for some N. WGate cannot be fixed like this, though, because there is ambiguity for WGate(0), which can be construed as either WGate(1) or WGate() (range(1) or range(0)). Since I know very little about quantum computing and Grover's algorithm, I'd like to know what the best way to fix this is. The options are see are: - Make WGate(0) be construed as range(1). Currently WGate(0) doesn't work, which leads me to believe that you can't have a gate with 0 quibits. This would not require breaking the current API, but might be confusing (?). You need to have at least 1 qubit for it to make sense. WGate(0) should really raise a ValueError. Right. WGate(0) would be the rebuild of WGate(1) (if that makes sense). - Break the API. Since any kind of break would be equally disruptive, I would suggest moving to just storing n in .args, and constructing reversed(range(n)) on the fly when it's needed. Alternately, we could store (reversed(range(n)),), which would make it similar to OracleGate. Yes, let's to that. Just make a property that returns reversed(range(n)) and use that when needed. OK. What should it be called? .quibits I guess. Should OracleGate (and maybe others?) also be changed? I would call it target_qubits and OracleGate should have the same thing. Cheers, Brian Aaron Meurer Does this answer your questions? Cheers, Brian Aaron Meurer -- Brian E. Granger Cal Poly State University, San Luis Obispo bgran...@calpoly.edu and elliso...@gmail.com -- Brian E. Granger Cal Poly State University, San Luis Obispo bgran...@calpoly.edu and elliso...@gmail.com -- You received this message because you are subscribed to the Google Groups sympy group. To post to this group, send email to sympy@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.
Re: [sympy] reworking expand [WAS] Suggestions for API fix in quantum module
On Wed, Jul 18, 2012 at 4:05 PM, Aaron Meurer asmeu...@gmail.com wrote:
Going back to TensorProduct, this is what I get in my branch:
In [58]: TensorProduct(x, y + z).expand()
Out[58]: x⋅y⋅1⨂ 1 + x⋅z⋅1⨂ 1
This is correct if x,y,z are scalars. If they are operators (or I
think other non-commuting symbols) you would get:
TensorProduct(x,y) + TensorProduct(x,z) = x⨂ y + x⨂ z
Cheers,
Brian
(I hope you mean the TensorProduct in sympy.physics.quantum). Is that
what you would expect? If, not, could you be more explicit about what
you are asking?
On Wed, Jul 18, 2012 at 4:44 PM, krastanov.ste...@gmail.com
krastanov.ste...@gmail.com wrote:
It uses is_Atom for the base case.
Why is is_Atom preferable to (not hasattr(obj, 'args') or not obj.args)?
Is not is_Atom redundant (i.e. mostly the same as args==(,)), and with
limited scope (i.e. breaks when args contain non-Basic)?
It works just fine with non-Basic args (I know this for a fact because
I had to make it work for OracleGate, which has a lambda in its args).
Let me go ahead and paste what I've been using:
def _eval_expand_hint(self, deep=True, **hints):
if not deep or self.is_Atom:
return self
sargs, terms = self.args, []
for term in sargs:
if hasattr(term, _eval_expand_hint):
newterm = term._eval_expand_hint(deep=deep, **hints)
else:
newterm = term
terms.append(newterm)
return self.func(*terms)
This is defined on Expr for each hint (actually a little more
generally using __getattr__, but that's external to the discussion).
I *suppose* self.is_Atom could be replaced with not self.args. I'm
not sure what the benefits of either way are. I do know there are
classes with empty .args that are not Atoms (like Tuple()). I don't
know of any classes that are recursion base cases but don't have args.
I think the key point about Atom is not that it has empty .args, but
that it has empty .args *and* it cannot be rebuilt from it's args (the
empty args part is only because this only works if it is always a leaf
in the expression tree). So Tuple().args == () but Tuple.is_Atom ==
False is fine because Tuple(*()) == Tuple() holds. But Symbol(*()) ==
Symbol('x') or Rational(*()) == Rational(1, 2) do not hold.
Note however that there's no way that .is_Atom or .args could not be
defined, because this is defined on Expr, so any class that uses it
will be a subclass of Expr and will have those properties.
Aaron Meurer
--
You received this message because you are subscribed to the Google Groups
sympy group.
To post to this group, send email to sympy@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.
--
Brian E. Granger
Cal Poly State University, San Luis Obispo
bgran...@calpoly.edu and elliso...@gmail.com
--
You received this message because you are subscribed to the Google Groups
sympy group.
To post to this group, send email to sympy@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.
[sympy] Re: Suggestions for API fix in quantum module
On Wed, Jul 18, 2012 at 12:13 PM, Aaron Meurer asmeu...@gmail.com wrote: In my branch where I'm fixing expand, I've moved the base _eval_expand functions to Expr. The result is that for expand to work on an object, it must be rebuildable via obj.func(*obj.args). There are two classes in the quantum module that came up where this doesn't work. One is OracleGate, which is built like OracleGate(2, lambda qubits: qubits == IntQubit(2)), which produces the .args ((0, 1), lambda qubits: qubits == IntQubit(2)) (in general, the first argument n is converted to range(n)). The second is WGate, which works like WGate(3), which produces the .args (2, 1, 0) (in general, an argument n produces reversed(range(n))). I was able to change OracleGate to accept its args without ambiguity. If the first argument is an integer, it does what it does now. If it's a tuple, succeed if it's of the form of range(N) for some N. WGate cannot be fixed like this, though, because there is ambiguity for WGate(0), which can be construed as either WGate(1) or WGate() (range(1) or range(0)). Since I know very little about quantum computing and Grover's algorithm, I'd like to know what the best way to fix this is. The options are see are: - Make WGate(0) be construed as range(1). Currently WGate(0) doesn't work, which leads me to believe that you can't have a gate with 0 quibits. This would not require breaking the current API, but might be confusing (?). You need to have at least 1 qubit for it to make sense. WGate(0) should really raise a ValueError. - Break the API. Since any kind of break would be equally disruptive, I would suggest moving to just storing n in .args, and constructing reversed(range(n)) on the fly when it's needed. Alternately, we could store (reversed(range(n)),), which would make it similar to OracleGate. Yes, let's to that. Just make a property that returns reversed(range(n)) and use that when needed. Does this answer your questions? Cheers, Brian Aaron Meurer -- Brian E. Granger Cal Poly State University, San Luis Obispo bgran...@calpoly.edu and elliso...@gmail.com -- You received this message because you are subscribed to the Google Groups sympy group. To post to this group, send email to sympy@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.
Re: [sympy] Location for Tr operation
One thing to be aware of is that the general Trace has to be able to handle partial traces of tensor products. This logic is implemented in this branch: https://github.com/sympy/sympy/pull/1396 And is somewhat specialized to the stuff in quantum, although it doesn't *depend* on quantum. Cheers, Brian On Thu, Jul 12, 2012 at 12:33 PM, Matthew Rocklin mrock...@gmail.com wrote: So do you think that the same object should trace over MatrixExpr, Matrix, and the physics classes? It seems to me that it should. Yes. I think that we can easily write a sufficiently general version of Trace, something like the Transpose object in this branch https://github.com/mrocklin/sympy/blob/transpose-decentralize/sympy/matrices/expressions/transpose.py -- Brian E. Granger Cal Poly State University, San Luis Obispo bgran...@calpoly.edu and elliso...@gmail.com -- You received this message because you are subscribed to the Google Groups sympy group. To post to this group, send email to sympy@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.
Re: [sympy] Location for Tr operation
On Thu, Jul 12, 2012 at 2:19 PM, Matthew Rocklin mrock...@gmail.com wrote: I had to look up partial trace (this is a new concept for me). After reading this I'm inclined to separate Trace and PartialTrace classes in an effort to optimize/simplify for the common case (at least the common case as I see it). Yes, the concept is quite subtle and not used (as far as I know) outside the context of quantum mechanics (where it is used a lot). I thought about having separate Trace and PartialTrace classes, but from the user API standpoint, they are really the same thing. Trace = Partial Trace over all indices Separating them adds complexity and confusion. Also in the current implementation, the partial trace logic doesn't affect the regular trace logic. The idea of a trace of a tensor product still sounds strange to me. I'm inclined to call this a tensor contraction. As I said though I'm not familiar with this specific notion of trace. It is sort of like a tensor contraction, but I don't think they are the same thing. Cheers, Brian On Thu, Jul 12, 2012 at 12:49 PM, Brian Granger elliso...@gmail.com wrote: One thing to be aware of is that the general Trace has to be able to handle partial traces of tensor products. This logic is implemented in this branch: https://github.com/sympy/sympy/pull/1396 And is somewhat specialized to the stuff in quantum, although it doesn't *depend* on quantum. Cheers, Brian On Thu, Jul 12, 2012 at 12:33 PM, Matthew Rocklin mrock...@gmail.com wrote: So do you think that the same object should trace over MatrixExpr, Matrix, and the physics classes? It seems to me that it should. Yes. I think that we can easily write a sufficiently general version of Trace, something like the Transpose object in this branch https://github.com/mrocklin/sympy/blob/transpose-decentralize/sympy/matrices/expressions/transpose.py -- Brian E. Granger Cal Poly State University, San Luis Obispo bgran...@calpoly.edu and elliso...@gmail.com -- Brian E. Granger Cal Poly State University, San Luis Obispo bgran...@calpoly.edu and elliso...@gmail.com -- You received this message because you are subscribed to the Google Groups sympy group. To post to this group, send email to sympy@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.
Re: [sympy] ipython configuration and isympy
I am fine if sympyprinting moves to sympy proper. IPython's extension loading mechanism works fine with anything in sys.path so we could do: %load_ext sympy.sympyprinting Or something like this. It should also remain in IPython though for the transition period. Cheers, Brian On Fri, Jun 15, 2012 at 2:20 AM, krastanov.ste...@gmail.com krastanov.ste...@gmail.com wrote: On 15 June 2012 11:03, Bharath M R catchmrbhar...@gmail.com wrote: I have been trying to get this working. Should we also bring the sympyprinting extension in IPython to sympy or leave it there? For additional configuration, we can have an ipython_config in interactive and call it when we run ipython with sympy. I would prefer that everything is kept inside sympy and not inside ipython. However you may want to ask Brian Granger what makes most sense (he is among the lead developers of ipython, I have cc-ed him). The only thing that I know is that Aaron already expressed the desire to have all in sympy in order to be able to make changes without pushing upstream to ipython. -- Brian E. Granger Cal Poly State University, San Luis Obispo bgran...@calpoly.edu and elliso...@gmail.com -- You received this message because you are subscribed to the Google Groups sympy group. To post to this group, send email to sympy@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.
[sympy] sympt-bot issue
Hi, On one machine that I have, I see the following when sympy-bot tries to upload the test results: Uploading test results Traceback (most recent call last): File ./sympy-bot, line 354, in module main() File ./sympy-bot, line 138, in main proto=proto File ./sympy-bot, line 336, in review report_url = reviews_sympy_org_upload(data, url_base) File /nfshome/bgranger/sympy/sympy-bot/utils.py, line 208, in reviews_sympy_org_upload return r[task_url] KeyError: 'task_url' Does this ring a bell to anyone? Cheers, Brian -- Brian E. Granger Cal Poly State University, San Luis Obispo bgran...@calpoly.edu and elliso...@gmail.com -- You received this message because you are subscribed to the Google Groups sympy group. To post to this group, send email to sympy@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.
Re: [sympy] Re: I am interested in applying to Google Summer of Code to work on a SymPy project
Luke, On Mon, Apr 2, 2012 at 1:23 PM, Luke hazelnu...@gmail.com wrote: Did you see my email about the Euler-Lagrange equations of motion that I sent earlier today? One important point is that there is absolutely no reason to have a custom Lagrangian class. You can just build the Lagrangian as a standard sympy expression. One reason to have a custom Lagrangian class is that it helps keep track of systems where you have a large number of particles/bodies/constraints/interacting forces. For simple systems you can surely write the Lagrangian in a line or two, but for more interesting systems, it becomes onerous and error prone to do this manually. Having a class which allows you to pass it a list of particles/bodies, and the forces/torques acting on them, as well as any kinematic constraints that may be present, greatly simplifies the work the user must do and reduces the likelihood of making a mistake. I see many reasons to have a custom Lagrangian class. OK, I can see that such a class would be useful for more complex systems, especially when things like constraints come into play. But, users should always be able to define a Lagrangian using regular sympy expressions. Also, the underlying Euler-Lagrange equations should work with regular sympy expressions as well. Cheers, Brian Luke -- You received this message because you are subscribed to the Google Groups sympy group. To post to this group, send email to sympy@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. -- Brian E. Granger Cal Poly State University, San Luis Obispo bgran...@calpoly.edu and elliso...@gmail.com -- You received this message because you are subscribed to the Google Groups sympy group. To post to this group, send email to sympy@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.
Re: [sympy] Re: I am interested in applying to Google Summer of Code to work on a SymPy project
Tim, On Mon, Apr 2, 2012 at 1:37 PM, Tim Lahey tim.la...@gmail.com wrote: On Mon, Apr 2, 2012 at 4:23 PM, Luke hazelnu...@gmail.com wrote: One reason to have a custom Lagrangian class is that it helps keep track of systems where you have a large number of particles/bodies/constraints/interacting forces. For simple systems you can surely write the Lagrangian in a line or two, but for more interesting systems, it becomes onerous and error prone to do this manually. Having a class which allows you to pass it a list of particles/bodies, and the forces/torques acting on them, as well as any kinematic constraints that may be present, greatly simplifies the work the user must do and reduces the likelihood of making a mistake. I see many reasons to have a custom Lagrangian class. I can see a reason to have a class to hold the Lagrangian (i.e., the work-energy expression), but the Euler-Lagrange equation itself should be broken out separately since it has uses far beyond mechanics. I've been thinking about writing support for general Calculus of Variations in SymPy, but it's likely to wait until the end of the summer at the earliest. The Euler-Lagrange module I posted as a sympy issue already handles most Lagrangians. The only thing I did not include is constraints, but that should not be too diffcult to add. Cheers, Brian Cheers, Tim. -- Tim Lahey PhD Candidate, Systems Design Engineering University of Waterloo http://about.me/tjlahey -- You received this message because you are subscribed to the Google Groups sympy group. To post to this group, send email to sympy@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. -- Brian E. Granger Cal Poly State University, San Luis Obispo bgran...@calpoly.edu and elliso...@gmail.com -- You received this message because you are subscribed to the Google Groups sympy group. To post to this group, send email to sympy@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.
[sympy] Euler-Lagrange equations
Hi, I know some of you are considering working on sympy.physics.mechanics for GSoC projects. Last summer I began to create a module that gives the Euler-Lagrange equations of motion for a Lagrangian. It would be a great pre-GSoC project to complete to demonstrate your abilities. Here is an issue that includes the current version of the module: http://code.google.com/p/sympy/issues/detail?id=3198 Even if this isn't completed as part of GSoC, we should finish this. Enjoy! Cheers, Brian -- Brian E. Granger Cal Poly State University, San Luis Obispo bgran...@calpoly.edu and elliso...@gmail.com -- You received this message because you are subscribed to the Google Groups sympy group. To post to this group, send email to sympy@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.
[sympy] Density matrix/operator issue
Hi, There has been some interest in the density operator/matrix implementation for sympy.physics.quantum. I have opened an issue to track this work. It points to a branch that has an initial implementation. http://code.google.com/p/sympy/issues/detail?id=3199 Cheers, Brian -- Brian E. Granger Cal Poly State University, San Luis Obispo bgran...@calpoly.edu and elliso...@gmail.com -- You received this message because you are subscribed to the Google Groups sympy group. To post to this group, send email to sympy@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.
[sympy] Quantum error correction
Hi, And finally, here is an issue for tracking work on quantum error correction in sympy. Again, there is a link to some initial code and standard refs on the subject. http://code.google.com/p/sympy/issues/detail?id=3200 Cheers, Brian -- Brian E. Granger Cal Poly State University, San Luis Obispo bgran...@calpoly.edu and elliso...@gmail.com -- You received this message because you are subscribed to the Google Groups sympy group. To post to this group, send email to sympy@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.
Re: [sympy] Re: I am interested in applying to Google Summer of Code to work on a SymPy project
Did you see my email about the Euler-Lagrange equations of motion that I sent earlier today? One important point is that there is absolutely no reason to have a custom Lagrangian class. You can just build the Lagrangian as a standard sympy expression. Please have a look at the issue I opened on this topic: http://code.google.com/p/sympy/issues/detail?id=3198 On Wed, Mar 28, 2012 at 2:35 PM, Elliot Marshall marshall2...@gmail.com wrote: Thank you all for the input. This is very helpful. I would like to get to the point where a Lagrangian class can be used to produce equations of motion outputted in whatever format is desired. Allowing the user to select the output format would allow him to proceed with simulation in whatever manner he is most comfortable/knowledgeable with. It would also be cool to integrate simulation using sympy.odeint for simple problems to quickly get from problem statement to simulation. Elliot On Tuesday, March 27, 2012 9:09:44 PM UTC-7, Aaron Meurer wrote: On Mar 27, 2012, at 6:19 PM, Luke hazelnu...@gmail.com wrote: For example, I would like to write the functions necessary so that, using sympy.physics.mechanics, one could use Euler, Lagrange, and possibly other methods to find the dynamical equations of motion for a system. Elliot, since the kinematics part of sympy.physics.mechanics is in pretty good shape, I would suggest outlining a Lagrange class, similar in some regards to the Kane class, which would let the user specify all information needed to construct the Lagrangian, and would then generate the equations of motion. Before you think to much about implementation, I think a valuable thing to do would be to write out sample use cases and code sessions which would show how a typical session would flow and would let you think about the interface the Lagrange class would have. Try coming up with a bunch of different interfaces to see what would be the most intuitive to somebody who has their dynamics book opened to chapter on Lagrange's method -- ideally I think you want a pretty close mapping between the math and the code you write to perform that math symbolically. sympy.physics.mechanics needs improvement in the department of code output. If implementing a Lagrange class proved straightforward, I think it would make sense to build a code output class which could take either a Kane object or a Lagrange object, and generate output code in python/C/fortran/matlab/??? format which would then be usable independently from the script you used to derive the equations in. Another idea on this front is to have a member function to the Kane or Lagrange class which could be passed directly to a python ODE integrator like scipy.odeint, eliminating the need to output code to file. This would allow you to derive and simulate all from the same script. This might only be feasible for small problems though since it will likely to be pretty slow. Also look at the already existing code generation module, to see what it can do and how it can be utilized. Aaron Meurer Also, I think it makes sense to first tackle the case where you are dealing with rigid bodies and you obtain ODE's, as opposed to flexible bodies where you obtain PDE's. Once that is complete and works reliably, it makes sense to pursue the flexible body case. I don't think it make sense to pursue the flexible case until after that though, and code output will vary significantly between the two because you obtain PDE's in one case and ODE's in the other. Luke On Tuesday, March 20, 2012 3:55:48 PM UTC-7, Elliot Marshall wrote: Hello world, I am a graduate student studying dynamics at UC Davis. We have been using a dynamics package for one of my classes that was written by some current graduate students in my research group. They have previous experience with GSoC developing this dynamics package. The package is by no means completed and I would like to work on developing it this summer. Any suggestions on how to go about the application process would be greatly appreciated. Thank you, Elliot Marshall -- You received this message because you are subscribed to the Google Groups sympy group. To view this discussion on the web visit https://groups.google.com/d/msg/sympy/-/50UcUmCEgGYJ. To post to this group, send email to sympy@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. -- Those who would give up essential liberty to purchase a little temporary safety deserve neither liberty nor safety. -- Benjamin Franklin, Historical Review of Pennsylvania, 1759 -- You received this message because you are subscribed to the Google Groups sympy group. To post to this group, send email to
Re: [sympy] [GSOC 2012] Interested in Symbolic Quantum Computing
Guru, I am a 3rd year PhD student in the Computer Science Department at University of Illinois,Chicago, working on Quantum Algorithms with a focus on graph problems. As part of GSOC 2012, I would like to work on implementing one/few of the ideas listed under Symbolic Quantum Computing. Great, nice to meet you. The list of topics below is a bit outdated, but I will comment on the specific items inline below. I see that there is a laundry list of 4+ items listed right now: Quantum Error Correction We have not done anything on this topics. It is a vast topic and would require a good knowledge of quantum computing and error correction. Would be very important and interesting though. Solovay-Kitaev algorithm I would google around to find the proposal on this topic from last summer (it was not selected). That would give you good ideas on how to proceed. This algorithm is pretty complex though so in your application you would need to demonstrate a solid understanding of it and how you would implement it. Gate+circuit simplification using genetic algorithms. I have had a student working on this during the year. He has made good progress and should be finishing up the work in the next month. His working pull request is here: https://github.com/sympy/sympy/pull/959 But I want to emphasize that there are many other things you could propose to do. If there are other topics that are close to your research, definitely bring them up for discussion. I also have a branch up with a good start to density matrices: https://github.com/ellisonbg/sympy/tree/densityop That would also make a very good GSOC project. Let me know if you are interested in that. I plan to go through the quantum modules and understand where the current implementation stands in terms of the above ideas during the next few days. Is it possible for someone here to give me pointers as well so that I don't go way offtrack trying to figure out what may be needed. I am also familiar with the libquantum C libraries that I have been using for my research. Are there things in libquantum that we don't have? For fulfilling the patch requirement, I have fixed one of the TODO items in the quantum module itself, that helped me get a head start. The pull request can be found here: https://github.com/sympy/sympy/pull/1137. Please let me know if this is sufficient. Another good thing to look at improving to get started is the circuit plotting. It is currently very basic and you could probably find many things to improve. Cheers, Brian -Guru -- You received this message because you are subscribed to the Google Groups sympy group. To view this discussion on the web visit https://groups.google.com/d/msg/sympy/-/8851BfklMKcJ. To post to this group, send email to sympy@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. -- Brian E. Granger Cal Poly State University, San Luis Obispo bgran...@calpoly.edu and elliso...@gmail.com -- You received this message because you are subscribed to the Google Groups sympy group. To post to this group, send email to sympy@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.
Re: [sympy] Sympy.physics.Quantum: GSoC 2012
On Tue, Mar 13, 2012 at 2:12 PM, Rhythm Gupta rhythm.gupt...@gmail.com wrote: Hello, While going through Ideas List. Some of those ideas caught my attention.And a few of them were really encouraging and motivational. The idea of Implementing All known Analytical Solutions to Quantum Mechanical Systems is really interesting because of its diverse use and benefits to the community. This can be used in most of the universities and colleges to help students learn Quantum Mechanics effectively. Freshers and sophomores are generally taught simple Quantum systems like 1-D(finite, infinite well,Oscillator), Simple harmonic Oscillator , Dirac functions , 3-D oscillator, hydrogen atoms,Rigid rotors and similar things.So i think it is good idea and i want to pursue this idea for my GSoC project this summer. As mentioned before, this aspect of the quantum work is currently in flux with Tomo's pull request that needs to be reviewed and merged. Also, just a warning: this part of sympy.quantum is incredible subtle and complex (as Tomo found out!). You will need to have an extremely (graduate level) understanding of quantum mechanics and top notch coding experience. If you want to do this, you should dig into the code (including Tomo's pull request) until you know it inside and out and can see what the next steps are. However i would like to get your inputs about the idea? Is this project big enough for a whole summer ? Definitely. Is it prioritized among other ideas? The other topic that is pretty high priority is updating the secondquant module to use the new sympy.quantum stuff. Cheers, Brian Whom to contact to discuss more about this topic and submitting a patch about it? Thanks, Rhythm Gupta. -- You received this message because you are subscribed to the Google Groups sympy group. To post to this group, send email to sympy@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. -- Brian E. Granger Cal Poly State University, San Luis Obispo bgran...@calpoly.edu and elliso...@gmail.com -- You received this message because you are subscribed to the Google Groups sympy group. To post to this group, send email to sympy@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.
Re: [sympy] GSOC 2012 : Quantum Module
Anurag, Welcome! I'm Anurag, a Physics student from the Indian Institute of Technology, Kanpur. I work on computational problems in quantum physics using various algorithms to solve the Schrodinger's equation. I would like to work on implementing position and momentum basis functions in sympy's Quantum module. The best starting place with this is to look at the work that was done last summer on this. To do that you will need to dig into the code in sympy.physics.quantum yourself and learn it inside and out. Also check out this pull request which has the rest of Tomo's work from last summer: https://github.com/sympy/sympy/pull/573 I don't want to discourage you but this stuff is pretty complex and will require a significant effort on your part to figure out where things are at. Cheers, Brian I've read the project idea and I think that along with the position and momentum basis kets and the respective operators 'X' 'P', it would be nice if we could define other operators like the Hamiltonian 'H', Kinetic energy 'T' and Potential 'V' in terms of the X and P operators which would surely help when solving cases like H atom or a Simple Harmonic oscillator. Other than that, defining a Fourier transformation from x to p will be useful and Implementing more advanced stuff like Time independent perturbations can be used to study energy level splitting. -- You received this message because you are subscribed to the Google Groups sympy group. To view this discussion on the web visit https://groups.google.com/d/msg/sympy/-/aj55SWqY2i8J. To post to this group, send email to sympy@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. -- Brian E. Granger Cal Poly State University, San Luis Obispo bgran...@calpoly.edu and elliso...@gmail.com -- You received this message because you are subscribed to the Google Groups sympy group. To post to this group, send email to sympy@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.
Re: [sympy] GSOC 2012
Hi, Welcome, On Tue, Feb 14, 2012 at 11:44 PM, shashank nagamalla.shashan...@gmail.com wrote: I am an undergraduate student currently doing my Masters in Physics and will be doing my B.E in Computer Science next year. I had done courses on quantum mechanics and I am comfortable to code in Python.I would very much like to be part of GSOC 2012 for SymPy. I was going through the 'Project Ideas' page and these projects particularly interest me: 1)Position and momentum basis functions This one is in a bit of a difficult situation because of an unmerged pull request from last summer: https://github.com/sympy/sympy/pull/573 But if you are interested I would dig into this code and try to figure out what the next steps are. Keep in mind, we want it to be completely general to handle: 1,2,3d, general coordinate systems, basis transformations, etc. 2)Abstract Dirac notation For this one, I would have a look at possibly tacking something like abstract perturbation theory, both time-dep and time-indep. That would make a nice project. 3)Implement All Known Analytical Solutions to Quantum Mechanical Systems. I think this one needs to wait until position/momentum are done. 4)Quantum mechanics on graphs I don't think this one is ready for a GSOC project. Apart from them i think we can implement Particle Physics library. Which includes- -Conservation laws -Feynman diagrams(can be shown using plot) and calculus ...etc You could also come up with your own ideas as well! Cheers, Brian I am not sure about how much(extent) it can be implemented in summer and weather it can be a project that can be done in sympy for GSOC. -- You received this message because you are subscribed to the Google Groups sympy group. To post to this group, send email to sympy@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. -- Brian E. Granger Cal Poly State University, San Luis Obispo bgran...@calpoly.edu and elliso...@gmail.com -- You received this message because you are subscribed to the Google Groups sympy group. To post to this group, send email to sympy@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.
Re: [sympy] ipython notebook, sympy, latex, and mathjax
To enable MathJax printing in the notebook do: * Start with the sympy profile: ipython notebook --profile sympy OR * Load the sympyprinting extension in a notebook: %load_ext sympyprinting Cheers, Brian On Sat, Feb 4, 2012 at 1:35 AM, lutusp lut...@gmail.com wrote: The sympy sampler located at http://live.sympy.org/ has an option setting to allow cell output to be rendered as plain text, unicode and latex (rendered by way of mathjax. But it seems the ipython notebook does have this feature (or I can't find it). It would be a nice enhancement to allow this output-format option in the ipython notebook and the qtconsole. Or have I just missed it? -- You received this message because you are subscribed to the Google Groups sympy group. To view this discussion on the web visit https://groups.google.com/d/msg/sympy/-/GgaOYkjX7joJ. To post to this group, send email to sympy@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. -- Brian E. Granger Cal Poly State University, San Luis Obispo bgran...@calpoly.edu and elliso...@gmail.com -- You received this message because you are subscribed to the Google Groups sympy group. To post to this group, send email to sympy@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.
Re: [sympy] Deprecation Cycles
I am -1 on establishing formal deprecation cycles or multiple APIs. For an open source project with limited manpower, these just hinder progress and confuse users. We are better off making good decisions, documenting them and moving forward quickly. Cheers, Brian On Wed, Jan 25, 2012 at 12:36 PM, Aaron Meurer asmeu...@gmail.com wrote: Hi. We've discussed this a little before. We currently are deprecating a lot of things, which I personally see as a good thing, because it means that we are cleaning up some old cruft. I would like to start some discussion about it, though, particularly about the length of deprecation cycles. I'd like to hear both from developers and from users. - First off, I think we can all agree that it's a good thing to set deprecation cycles specifically, so that users will know exactly when they can expect the old feature to be removed. My questions below rely on this assumption. - Do you think we should have a set deprecation cycle length, or should we decide each on a per-case basis? We could also set different lengths for different situations, e.g., if the feature change would likely cause severe problems in many people's code, we could make the cycle longer. On the other hand, if some now feature is blocked on removing deprecated behavior, we could make it shorter. Even if you think the answer to the above question is per-case, the rest of these are still worth discussing. But if you think they should be set, what should they be set to? - Should deprecation cycles be time based or version based? On the one hand, our release cycle is irregular, and will remain so for the foreseeable future. We went over a year between 0.6.7 and 0.7.0. Then we went just over a month to release 0.7.1. So there may be something to be said for having time based cycles instead of release based ones (the next release after February 1, 2013 or something like that). On the other hand, there's no telling how SymPy itself will advance in a given period of time (I guess the same can be true about releases themselves, but there's at least some guarantee of a certain amount of changes for every 0.0.1 or 0.1 release). I think no release will be under a month, unless we find some minor problem with a release immediately after it goes out. In that case, I think we should do a 0.0.0.1 release (like 0.7.2.1 for example). So I think that if we do release based deprecations, we should set a specific release, not +2 releases or something like that, to handle potential 0.0.0.1 releases. The question here is what should we do about 0.1 releases? I don't think these should happen very often, only when we have a very significant change in the codebase, (e.g., for 0.7.0 we had the new polys). But if we say this feature will be removed by 0.7.4 and the next release after 0.7.3 is 0.8.0, then that could cause confusion. We could be precise and say the next two 0.0.1 or 0.1 releases, but that starts to get confusing fast. - I discussed the implementation of this in another thread, and I don't think there were any disagreements. The idea was to add flags to SymPyDeprecationWarning (and to @deprecated, which would pass them through), which would build up a deprecation string with the relevant information. We would also do necessary tracking in the issues to make sure old features are removed when they should be. Here are two examples of things we deprecated or plan to deprecate, so you can get an idea of the sorts of things I'm talking about: - In 0.7.0, we renamed Real to Float. We kept Real and .is_Real as deprecated shortcuts to Float and .is_Float, respectively. This is a good example of a fairly harmless deprecation. Keeping the old names around indefinitely would not harm anything, other than that they clutter things up. Furthermore, if they were removed, it would be trivial for users to fix their code, and, perhaps more importantly, it would be easy for them to tell that they would need to do that, because they would get ImportError or AttributeError, which would clearly tell them that Real was not defined any more. A simple Google search or question here would reveal that it's been renamed to Float. - In https://github.com/sympy/sympy/pull/1009, we are changing the syntax for Piecewise. The current syntax is Piecewise((expr1, cond1), (expr2, cond2), ..., (exprn, condn), (otherwise, True)). For example, Piecewise((1, x 0), (2, x 0), (0, True)) means 1 if x is negative, 2 if x is positive, and 0 otherwise. However, the use of True to signify the otherwise condition is problematic, because a user may enter, either manually or programmatically, a condition that automatically evaluated to True. So something like Piecewise((1, x 0), (2, 1 0)) would evaluate to a Piecewise, not 2 as would be expected. The solution is to change the syntax to Piecewise((expr1, cond1), ..., (exprn, condn), otherwise), where the
Re: [sympy] Deprecation Cycles
On Thu, Jan 26, 2012 at 9:38 AM, Aaron Meurer asmeu...@gmail.com wrote: So are you -1 just to setting specific time/version lengths to deprecate things, or is it more? In some cases it is more. In some cases (like Real/Float) it is possible to keep the older API around and put a dep. warning on it. For the more mature parts of our code base, I am fine with this approach - even adding version information like are you are proposing. In other cases (like Piecewise) that is impossible without going through horrible contortions. In those cases I don't think we should make any attempt to deprecate the older API - just document it well in release notes. Also, for less mature parts of the code base that are still moving quickly, I don't think there is any need to issue deprecation warnings. Basically, I feel that we should optimize for ease of development, not API stability. Do you think it's a bad idea to even say at all that we should decide beforehand how long something is deprecated, and tell the user that? The reason I ask is that I want to implement that API in SymPyDeprecationWarning so that you can call it with args, like SymPyDeprecationWarning(feature=blah, last_version=0.7.3, ...), and it would convert the string into something like Feature blah is deprecated and will be removed after 0.7.3 But just having this in place will end up creating a soft requirement that people use it. Aaron Meurer On Thu, Jan 26, 2012 at 10:33 AM, Brian Granger elliso...@gmail.com wrote: I am -1 on establishing formal deprecation cycles or multiple APIs. For an open source project with limited manpower, these just hinder progress and confuse users. We are better off making good decisions, documenting them and moving forward quickly. Cheers, Brian -- You received this message because you are subscribed to the Google Groups sympy group. To post to this group, send email to sympy@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. -- Brian E. Granger Cal Poly State University, San Luis Obispo bgran...@calpoly.edu and elliso...@gmail.com -- You received this message because you are subscribed to the Google Groups sympy group. To post to this group, send email to sympy@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.
Re: [sympy] secondquant classes
On Thu, Jan 12, 2012 at 9:50 PM, smichr smi...@gmail.com wrote: Two questions: 1) Why do FockStateKet and FockStateBra print as FockState? BKet((n,)) FockState((n,)) BBra((n,)) FockState((n,)) I think these were created as shorthand aliases. Probably not the best decision. The Bra and Ket derive from FockState, so sympification of these (misrepr-s) will fail to give the original object and are misleading as to what one is dealing with, e.g. a,b=AnnihilateBoson(0), BKet((n,)) a,b (AnnihilateBoson(0), FockState((n,))) a.apply_operator(b) sqrt(n)*FockStateBosonKet((n - 1,)) a.apply_operator(S(repr(b))) AnnihilateBoson(0)*FockState((n,)) 2) Why, though class FockStateBosonKet is defined in secondquant, does importing everything not give access to that, but only to the alias that is defined? Bad design decision. This entire module needs to be rewritten though, so I wouldn't spend too much time worrying about these things. But we should probably avoid aliasing like this. from sympy.physics.secondquant import * FockStateBosonKet Traceback (most recent call last): File stdin, line 1, in module NameError: name 'FockStateBosonKet' is not defined BKet # the line BKet = FockStateBosonKet appears in the file class 'sympy.physics.secondquant.FockStateBosonKet' -- You received this message because you are subscribed to the Google Groups sympy group. To post to this group, send email to sympy@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. -- Brian E. Granger Cal Poly State University, San Luis Obispo bgran...@calpoly.edu and elliso...@gmail.com -- You received this message because you are subscribed to the Google Groups sympy group. To post to this group, send email to sympy@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.
Re: [sympy] Re: Getting rid of tiny imaginary parts in eigenvalues
On Sat, Dec 10, 2011 at 10:37 AM, pedda notforyou...@hmamail.com wrote: I have tried to do it non-symbolically, but I think it is rather inelegant. I am also trying to promote the use of python/sage over the use of Mathematica with my fellow students and it is somewhat important to show that they can do the same thing for free with other advantages. Since Mathematica is able to calculate the eigenvalues without any problem or delay, it is hard to convince someone to switch to a system that takes so much longer and is not as reliable. I just installed the python3 version of sympy, which didn't it done either... You can by the way eliminate the recursion depth error by adding sys.setrecursionlimit(2**20) to your file. So far, this is what I found out from testing with various systems: Sage with python 2.6: calculates up to 36x36 in a reasonable time (65s) python 2.7/python 3.2: calculate up to ~ 20x20 Sage with Maxima for calculation works faster, but I have problem with really big matrices like 400x400 ... working on it though! Some perspective is appropriate: * Finding eigenvalues symbolically for anything for very small matrices is incredible slow and the answers you get are not going to be meaningful symbolically - you are going to want numerical answers. I am not saying sympy's algorithms couldn't be better. * 400x400 is a small matrix for numerical computations. By insisting on using a symbolic algorithm, you are making an easy problem hard. Moving to a numerical approach would allow you to handle matrices of *many* thousands of rows/columns almost instantly. * For these types of matrices you really should be using the sparse matrices in scipy.sparse. Otherwise you are wasting a ton of time storing and multiplying zeros. Cheers, Brian -- You received this message because you are subscribed to the Google Groups sympy group. To post to this group, send email to sympy@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. -- Brian E. Granger Cal Poly State University, San Luis Obispo bgran...@calpoly.edu and elliso...@gmail.com -- You received this message because you are subscribed to the Google Groups sympy group. To post to this group, send email to sympy@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.
[sympy] SymPy quantum computing paper
Hi, We have done a lot of work on SymPy's quantum computing modules and it is time to write a paper. If you are interesting in helping out, please read on... * The paper will focus on SymPy's quantum computing modules in sympy.physics.quantum (gate, qubit, qft, etc.). We should also write a more general paper on sympy.physics.quantum, but that will come later. * We will have a short introduction to SymPy and sympy.physics.quantum. * It will be submitted to either Physical Review X (open online journal) or a more specialized quantum information journal. Phys. Rev X would be ideal as it is completely free and open, but the cost is $1500. I will see if I can come up with that money though. * The author list will be determined as follows: 1) anyone who has done significant work on the quantum information stuff will automatically be co-authors 2) anyone who is a contributor to SymPy and wants to help write/read/proof the paper is also welcome to be a co-author * Much of the paper will be code demos with nice latex output. This will be done as a set of IPython notebooks. I would like to publish these with the paper. Here is the repo where this work is going to happen: https://github.com/ellisonbg/sympy-qcpaper Cheers, Brian -- Brian E. Granger Cal Poly State University, San Luis Obispo bgran...@calpoly.edu and elliso...@gmail.com -- You received this message because you are subscribed to the Google Groups sympy group. To post to this group, send email to sympy@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.
Re: [sympy] SymPy quantum computing paper
2011/12/6 Ondřej Čertík ondrej.cer...@gmail.com: Hi Brian, On Tue, Dec 6, 2011 at 12:24 PM, Brian Granger elliso...@gmail.com wrote: Hi, We have done a lot of work on SymPy's quantum computing modules and it is time to write a paper. If you are interesting in helping out, please read on... * The paper will focus on SymPy's quantum computing modules in sympy.physics.quantum (gate, qubit, qft, etc.). We should also write a more general paper on sympy.physics.quantum, but that will come later. Absolutely. It will force me to contribute more general stuff into the quantum module. :) Great. * We will have a short introduction to SymPy and sympy.physics.quantum. * It will be submitted to either Physical Review X (open online journal) or a more specialized quantum information journal. Phys. Rev X would be ideal as it is completely free and open, but the cost is $1500. I will see if I can come up with that money though. * The author list will be determined as follows: 1) anyone who has done significant work on the quantum information stuff will automatically be co-authors 2) anyone who is a contributor to SymPy and wants to help write/read/proof the paper is also welcome to be a co-author * Much of the paper will be code demos with nice latex output. This will be done as a set of IPython notebooks. I would like to publish these with the paper. Here is the repo where this work is going to happen: https://github.com/ellisonbg/sympy-qcpaper Thanks a lot for the initiative. Here is my first pull request: https://github.com/ellisonbg/sympy-qcpaper/pull/1 Thanks, I already merged it! Cheers, Brian Ondrej -- You received this message because you are subscribed to the Google Groups sympy group. To post to this group, send email to sympy@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. -- Brian E. Granger Cal Poly State University, San Luis Obispo bgran...@calpoly.edu and elliso...@gmail.com -- You received this message because you are subscribed to the Google Groups sympy group. To post to this group, send email to sympy@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.
Re: [sympy] Re: A Quantum Module Question
The pull request linked to above has been merged into master, so this issue should be fixed. Cheers, Brian 2011/11/5 Uğur Güney ugurgu...@gmail.com: On Sat, Nov 5, 2011 at 3:39 PM, smichr smi...@gmail.com wrote: from sympy import * from sympy.physics.quantum import * from sympy.physics.quantum.qubit import * q0 = Qubit(S(0)) q1 = Qubit(S(1)) state = TensorProduct(q0,q1) # a 2-qubit state id = q0*Dagger(q0)+q1*Dagger(q1) # identity proj = TensorProduct(id, q1*Dagger(q1)) # a projection op. IxP on H1xH2 print qapply(tensor_product_simp(proj*state)) # error To make it clear I wrote down the intended calculation here:http://mathurl.com/3pe3v7cIt fails at qapply step. I did some editing of the quantum modules and I now obtain (for the above): |0x|1 If this is right, perhaps you or Brian can review this at https://github.com/sympy/sympy/pull/699 Thanks! I can not say anything about the SymPy source code but the result you obtained is now correct. vug -- You received this message because you are subscribed to the Google Groups sympy group. To post to this group, send email to sympy@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. -- You received this message because you are subscribed to the Google Groups sympy group. To post to this group, send email to sympy@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. -- Brian E. Granger Cal Poly State University, San Luis Obispo bgran...@calpoly.edu and elliso...@gmail.com -- You received this message because you are subscribed to the Google Groups sympy group. To post to this group, send email to sympy@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.
Re: [sympy] Multiplication of two Tensor Products
Yes, here is a note in tensor_product_simp_Mul: # TODO: This won't work with Muls that have other composites of # TensorProducts, like an Add, Pow, Commutator, etc. But the expand should do the trick for now. 2011/11/8 Uğur Güney ugurgu...@gmail.com: I realized that when I try to multiply two objects, a tensor product and a sum of tensor products, SymPy makes a wrong calculation. For example, say, this is what I am trying to compute: http://mathurl.com/cfj5zfc The answer must be zero at the end. This is what SymPy does at tensor_product_simp step: http://mathurl.com/cc5sxlz which is incorrect. Here is the code I am using: from sympy import * from sympy.physics.quantum import * from sympy.physics.quantum.qubit import * q0 = Qubit(0) q1 = Qubit(1) state = TensorProduct(q0,q0)+TensorProduct(q1,q0) # state as a sum of tensor products op = TensorProduct(1, q0*Dagger(q1)) # a operator as a tensor product print tensor_product_simp(op*state) # ? print print qapply(tensor_product_simp(op*state)) # operator applied to the state, answer must be 0 but it is not. What I understand is that tensor_product_simp() does this: (AxB)(CxD) - ACxBD. But here, instead of (CxD) I have (CxD+ExF). And t_p_s() gives something like: A(CxD+ExF)xB(CxD+ExF), which is incorrect. It must be (AxB)(CxD)+(AxB)(ExF)=ACxBD+AExBF. Actually I am not sure whether this is my mistake or tensor_product_simp()'s mistake. :-) Maybe it is not intended to do this kind of calculations. Regards, vug -- You received this message because you are subscribed to the Google Groups sympy group. To post to this group, send email to sympy@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. -- Brian E. Granger Cal Poly State University, San Luis Obispo bgran...@calpoly.edu and elliso...@gmail.com -- You received this message because you are subscribed to the Google Groups sympy group. To post to this group, send email to sympy@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.
Re: [sympy] Multiplication of two Tensor Products
On Tue, Nov 8, 2011 at 9:43 PM, Chris Smith smi...@gmail.com wrote: If I recall tensor_product_simp is designed to handle the TensorProduct()*TensorProduct() case only. Try doing this: tensor_product_simp(expand(op*state)) Should an expand_mul be part of the simp routine itself? Yes, but the logic is quite a bit more complex. When tensor_product_simp gets passed a Mul, it calls tensor_product_simp_Mul which has the logic for that case. The challenge is that any arg of that Mul could be something like: * an Add with TensorProducts * a Pow of TensorProdiucts * Commutator/Anticommutators of TensorProducts And such expression can be nested arbitrarily deep. Throwing in an expand_mul will only cover the case where one or more of the arguments passed to tensor_product_simp_Mul is an Add. Separate logic is needed for the other cases. Cheers, Brian -- You received this message because you are subscribed to the Google Groups sympy group. To post to this group, send email to sympy@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. -- Brian E. Granger Cal Poly State University, San Luis Obispo bgran...@calpoly.edu and elliso...@gmail.com -- You received this message because you are subscribed to the Google Groups sympy group. To post to this group, send email to sympy@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.
Re: [sympy] A Quantum Module Question
2011/11/4 Uğur Güney ugurgu...@gmail.com:
Now, I can ask my second question. :-)
Are the states and operators aware of their Hilbert spaces? For example,
say, I'm working on a two particle system. I'm only looking at their spin
states, described by qubits. First particle lives in Hilbert space H1, and
second one in H2. So the combined state lives in H1xH2. I want to apply
projection operators which works on either H1 or H2 to this state.
I tried this:
All of the Hilbert space stuff is implicit, but you can still do what you want.
H1=HilbertSpace() # Hilbert space for first particle
H2=HilbertSpace() # Hilbert space for second particle
qb1 = Qubit('0') # first particle's state
qb2 = Qubit('1') # second particle's state
state = TensorProduct(qb1,qb2) # state of combined system
# state.hilbert_space # gave an error: no such attribute
proj = qb2*qb2.dual # projection operator which works on H2
proj = TensorProduct(1, qb2*qb2.dual)
qapply(tensor_product_simp(proj*state))
The extra tensor_product_simp turns a product of TPs into a TP of products.
But the main point is that you have to be careful about creating
tensor products explicitly. This is another place where we tend to be
very sneaky when writing Dirac notation by hand. We keep track of
which Hilbert space each operator is acting in but don't express it in
our notation. As you can imagine, it was quite difficult to teach
SymPy Dirac notation and we have tried to strike a balance between
Mathematical accuracy and easy of use.
Cheers,
Brian
proj*state
(proj*state).doit()
qapply(proj*state)
The result was: |11|*|0x|1 Is it possible to convert this expression
into |0x(|11|1) which can be further simplified to |0x|1?
vug
2011/11/4 Uğur Güney ugurgu...@gmail.com
Hi!
Thanks for the clear explanation!
On Fri, Nov 4, 2011 at 1:27 AM, Brian Granger elliso...@gmail.com wrote:
Ugur,
Welcome!
2011/11/3 Uğur Güney ugurgu...@gmail.com:
Dear Sympy users,
I'm a physics PhD student, doing research on differences between
classical
and quantum correlations.
I was in need of a simple calculator which works with quantum states
etc.
While searching for quantum simulators in Python I came to know that
there
is already a quantum module in SymPy. Because I couldn't find an
explicit
documentation I looked at the source files to understand how basic
calculations can be done using the quantum module.
Great, currently this is the best way to learn about how it all works.
Can you please help me in applying a projection operator on a general
state.
This is the code that I tried:
from sympy import *
from sympy.physics.quantum import *
from sympy.physics.quantum.qubit import *
[c00,c01,c10,c11]=var('c00,c01,c10,c11') # coefficients
state = c00*Qubit('00')+c01*Qubit('01')+c10*Qubit('10')+c11*Qubit('11')
#
most general two-qubit state
qbt=Qubit('01') # a qubit
proj = qbt*qbt.dual # projection operator
# proj*state # operator applied on the state
The following will work:
qapply(proj*state)
The need for qapply (quantum apply) is as follows. Because of how
python/sympy handle multiplication, we are only able to detect inner
products in very simple situations like Qubit('01').dual*Qubit('01').
For more complex situations, we just leave it as a general
multiplication operation. The qapply function walks through a
general quantum expression and does a couple of things:
* Applies any operators to states.
* Looks for bra|*|ket expressions and turns them into inner products.
This is why you need to call qapply by hand after creating a general
quantum expression.
Now I realized that even the simplest calculation that is made with pencil
and paper involves these kind of background processes that we
do unconsciously. Dirac notation is too intuitive for a computer. :-)
Hope this helps. Also, we would love to know how you end up using
this stuff. It is pretty new, so there is a ton left to do. Also, if
you are looking at classical/quantum correlations, you may be
interested in the work we have done on density matrices. That has not
yet been merged into sympy's master branch, but we plan on doing
thatalways looking for help.
Thanks! OK, I will inform the group about how and where I used Sympy. I'll
definitely look at density matrices because I want to work on both pure
states and mixed states.
vug
Cheers,
Brian
# (proj*state).expand() operator applied on each term in the expansion
print (proj*state).expand().doit() # try to do the inner-products
In the last step doit() did not work as I expected, it did not do the
inner products. I suspect that the expression involving TensorProduct
is not
converted to InnerProduct automatically. But normally
(Qubit('01').dual*Qubit('01')).doit() and
(Qubit('00').dual*Qubit('01')).doit() work as expected and give 1 and
0.
I'll be happy if you can guide me how to use this beautiful tool.
Best,
ugur guney
Re: [sympy] A Quantum Module Question
Yep Aaron is right, this is a bug. On Fri, Nov 4, 2011 at 10:30 AM, Aaron Meurer asmeu...@gmail.com wrote: But, unforunately, when I tried proj=TensorProduct(1,qb2*qb2.dual) I got this error: AttributeError: 'int' object has no attribute 'is_commutative' I think 1 is an integer an does not behaved as an identity operator. Are there any identity operators in Sympy? vug This is a bug in the quantum module. It needs to have a SymPy Integer, not a Python int. The quantum function should do this conversion automatically, but it seems that this one doesn't. Try using TensorProduct(Integer(1),qb2*qb2.dual) as a workaround. Aaron Meurer -- You received this message because you are subscribed to the Google Groups sympy group. To post to this group, send email to sympy@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. -- Brian E. Granger Cal Poly State University, San Luis Obispo bgran...@calpoly.edu and elliso...@gmail.com -- You received this message because you are subscribed to the Google Groups sympy group. To post to this group, send email to sympy@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.
Re: [sympy] A Quantum Module Question
Ugur,
Welcome!
2011/11/3 Uğur Güney ugurgu...@gmail.com:
Dear Sympy users,
I'm a physics PhD student, doing research on differences between classical
and quantum correlations.
I was in need of a simple calculator which works with quantum states etc.
While searching for quantum simulators in Python I came to know that there
is already a quantum module in SymPy. Because I couldn't find an explicit
documentation I looked at the source files to understand how basic
calculations can be done using the quantum module.
Great, currently this is the best way to learn about how it all works.
Can you please help me in applying a projection operator on a general state.
This is the code that I tried:
from sympy import *
from sympy.physics.quantum import *
from sympy.physics.quantum.qubit import *
[c00,c01,c10,c11]=var('c00,c01,c10,c11') # coefficients
state = c00*Qubit('00')+c01*Qubit('01')+c10*Qubit('10')+c11*Qubit('11') #
most general two-qubit state
qbt=Qubit('01') # a qubit
proj = qbt*qbt.dual # projection operator
# proj*state # operator applied on the state
The following will work:
qapply(proj*state)
The need for qapply (quantum apply) is as follows. Because of how
python/sympy handle multiplication, we are only able to detect inner
products in very simple situations like Qubit('01').dual*Qubit('01').
For more complex situations, we just leave it as a general
multiplication operation. The qapply function walks through a
general quantum expression and does a couple of things:
* Applies any operators to states.
* Looks for bra|*|ket expressions and turns them into inner products.
This is why you need to call qapply by hand after creating a general
quantum expression.
Hope this helps. Also, we would love to know how you end up using
this stuff. It is pretty new, so there is a ton left to do. Also, if
you are looking at classical/quantum correlations, you may be
interested in the work we have done on density matrices. That has not
yet been merged into sympy's master branch, but we plan on doing
thatalways looking for help.
Cheers,
Brian
# (proj*state).expand() operator applied on each term in the expansion
print (proj*state).expand().doit() # try to do the inner-products
In the last step doit() did not work as I expected, it did not do the
inner products. I suspect that the expression involving TensorProduct is not
converted to InnerProduct automatically. But normally
(Qubit('01').dual*Qubit('01')).doit() and
(Qubit('00').dual*Qubit('01')).doit() work as expected and give 1 and 0.
I'll be happy if you can guide me how to use this beautiful tool.
Best,
ugur guney
--
You received this message because you are subscribed to the Google Groups
sympy group.
To post to this group, send email to sympy@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.
--
Brian E. Granger
Cal Poly State University, San Luis Obispo
bgran...@calpoly.edu and elliso...@gmail.com
--
You received this message because you are subscribed to the Google Groups
sympy group.
To post to this group, send email to sympy@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.
Re: [sympy] circuit_plot
Hi, On Thu, Oct 6, 2011 at 11:54 AM, Hans Harhoff Andersen hansharh...@gmail.com wrote: Hi Sympy. I am trying to use circuit_plot to plot my quantum circuit. I can get CNOT and such gates working, but I can't get the Toffoli/CCNOT gate to plot. As I read the documentation I should be able to use mutiple control qubits on the CNOT gate by writing something like: gate.CNOT([2,1],0) to have qubit 1 and 2 control qubit 0. But this doesn't work with sympy 0.7. The CNotGate in sympy is strictly a two qubit gate, taking only a single control qubit. What you want to use in the more general CGate: g = CGate((0,1),X(2)) The plotting for that should work fine. Any hints or suggestions? -- You received this message because you are subscribed to the Google Groups sympy group. To post to this group, send email to sympy@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. -- Brian E. Granger Cal Poly State University, San Luis Obispo bgran...@calpoly.edu and elliso...@gmail.com -- You received this message because you are subscribed to the Google Groups sympy group. To post to this group, send email to sympy@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.
Re: [sympy] Re: circuit_plot
On Thu, Oct 6, 2011 at 12:13 PM, Hans Harhoff Andersen hansharh...@gmail.com wrote: I suspect that this is a bug since I can get it to work by writing: gate.CGate((2,1),gate.X(0)) When I do gate.CNOT((2,1),0) I get: TypeError: List indices must be integers, not Tuple Yep you got it. On Thu, Oct 6, 2011 at 8:54 PM, Hans Harhoff Andersen hansharh...@gmail.com wrote: Hi Sympy. I am trying to use circuit_plot to plot my quantum circuit. I can get CNOT and such gates working, but I can't get the Toffoli/CCNOT gate to plot. As I read the documentation I should be able to use mutiple control qubits on the CNOT gate by writing something like: gate.CNOT([2,1],0) to have qubit 1 and 2 control qubit 0. But this doesn't work with sympy 0.7. Any hints or suggestions? -- You received this message because you are subscribed to the Google Groups sympy group. To post to this group, send email to sympy@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. -- Brian E. Granger Cal Poly State University, San Luis Obispo bgran...@calpoly.edu and elliso...@gmail.com -- You received this message because you are subscribed to the Google Groups sympy group. To post to this group, send email to sympy@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.
Re: [sympy] Re: circuit_plot
On Thu, Oct 6, 2011 at 2:19 PM, Hans Harhoff Andersen hansharh...@gmail.com wrote: I just checked that the problem persists even in newest git version. I should mention that I don't consider this to be a bug as most people use the word CNOT gate to mean the two qubit gate. Also I have a feature request for circuit_plot. It would be very nice to have a way of making circuit plot display unfilled circles for controls which are triggered on qubit being in 0 state instead of state 1 (cf. Nielsen and Chuang book for examples of this eg. page 193 (fig. 4.16)). Without this feature you have to include a lot of NOTs in your circuit digram which makes it ugly and unreadable. A simple subclass of CGate would accomplish this: class AntiCGate(CGate): control_value = Integer(0) def plot_gate(self, circ_plot, gate_idx): min_wire = int(min(chain(self.controls, self.targets))) max_wire = int(max(chain(self.controls, self.targets))) circ_plot.control_line(gate_idx, min_wire, max_wire) for c in self.controls: circ_plot.anti_control_point(gate_idx, int(c)) self.gate.plot_gate(circ_plot, gate_idx) This would also require the anti_control_point method of circuitplot.CircuitPlot: def anti_control_point(self, gate_idx, wire_idx): Draw a control point. x = self._gate_grid[gate_idx] y = self._wire_grid[wire_idx] radius = self.control_radius c = Circle( (x,y), radius*self.scale, ec='k', fc='k', fill=False, lw=self.linewidth ) self._axes.add_patch(c) Could you create a pull request on github with these changes? I am short on time right now and won't be able to get to this for a while. If you can't create a pull request, please open an issue with this information. Cheers, Brian Best regards, Hans On Oct 6, 9:13 pm, Hans Harhoff Andersen hansharh...@gmail.com wrote: I suspect that this is a bug since I can get it to work by writing: gate.CGate((2,1),gate.X(0)) When I do gate.CNOT((2,1),0) I get: TypeError: List indices must be integers, not Tuple On Thu, Oct 6, 2011 at 8:54 PM, Hans Harhoff Andersen hansharh...@gmail.com wrote: Hi Sympy. I am trying to use circuit_plot to plot my quantum circuit. I can get CNOT and such gates working, but I can't get the Toffoli/CCNOT gate to plot. As I read the documentation I should be able to use mutiple control qubits on the CNOT gate by writing something like: gate.CNOT([2,1],0) to have qubit 1 and 2 control qubit 0. But this doesn't work with sympy 0.7. Any hints or suggestions? -- You received this message because you are subscribed to the Google Groups sympy group. To post to this group, send email to sympy@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. -- Brian E. Granger Cal Poly State University, San Luis Obispo bgran...@calpoly.edu and elliso...@gmail.com -- You received this message because you are subscribed to the Google Groups sympy group. To post to this group, send email to sympy@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.
Re: [sympy] Re: sympy.physics.quantum reference/docs/examples
On Mon, Sep 19, 2011 at 11:48 PM, Chris Smith smi...@gmail.com wrote: Qubit(0,0)*Qubit(0) but qapply doesn't understand that I want the tensor product between the qubits. Is there a way to tell sympy to treat the * between the qubits as a tensorproduct? Does this work? TensorProduct(Qubit(0,0), Qubit(0)) Yep, the * operator in is already being used for non-tensor products, so you have to construct them using the TensorProduct class. We currently do not have a function that automatically does the transformation: TensorProduct(Qubit(0,0), Qubit(0)) - Qubit(0,0,0) But it probably makes sense to have a function in the quantum computing modules that does this. It would be a good small project for someone... /c -- You received this message because you are subscribed to the Google Groups sympy group. To post to this group, send email to sympy@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. -- Brian E. Granger Cal Poly State University, San Luis Obispo bgran...@calpoly.edu and elliso...@gmail.com -- You received this message because you are subscribed to the Google Groups sympy group. To post to this group, send email to sympy@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.
Re: [sympy] sympy.physics.quantum reference/docs/examples
Hans, On Mon, Sep 19, 2011 at 12:03 PM, Hans Harhoff Andersen hansharh...@gmail.com wrote: Hi. I have been trying to figure out how to use sympy.physics.quantum specifically the qubit/gate part. I have gotten qubits working and I have applied various operators to them (with some guesswork/trial-and- error), but I can't figure out how to define my own operators. I'd like to provide a matrix which should then become an operator/gate. How do I do this. I have tried using gate.UGate but I complains that my matrices do not have is_integer method. I don't remember exactly but I think that UGate may not be fully working. It should not be difficult to fix the problems though. But, in the meantime if you simply want to create a new single qubit gate, I would look at the implementation of the existing single qubit gates. It should be quite simple to follow that pattern and create your own subclass. As far as UGate goes, could you file a bug report on sympy's issues page? Is there a good place for examples/documentation of how to use the quantum package in general and qubits in specific? Right now the best place to learn about it is the code itself, as well as the tests. Best regards, Hans -- You received this message because you are subscribed to the Google Groups sympy group. To post to this group, send email to sympy@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. -- Brian E. Granger Cal Poly State University, San Luis Obispo bgran...@calpoly.edu and elliso...@gmail.com -- You received this message because you are subscribed to the Google Groups sympy group. To post to this group, send email to sympy@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.
Re: [sympy] Re: sympy.physics.quantum reference/docs/examples
On Tue, Sep 20, 2011 at 8:46 AM, Addison Cugini ajcug...@gmail.com wrote: Hey Hans, It's been a while since I have had any time to code for this, so the density operator stuff is nowhere near ready to be integrated into Sympy. The test suite I have put in place is pretty small, so I have not really validated the software. (Nor is the way I implement some things the way I would like) With that warning in place, you can find the density operator code on my personal github repository under the branch 'density'. https://github.com/addisonc/sympy/tree/density It might be a good idea to wait for a Dr Brian Granger to respond, as he (or one of his new students) might have added some things to the code base since I last touched it. We have not done anything further with this, but we definitely would love to get this finished and merged. I probably won't have any time to work on it, but if anyone wants to take a shot at it, let me know. Cheers, Brian Cheers, Addison Cugini On Tue, Sep 20, 2011 at 7:49 AM, Hans Harhoff Andersen hansharh...@gmail.com wrote: Ok, thanks I will wait for his reply then. Mean while I found a working copy of the density operator function in a github fork (repo of addisonc). It just sounded from the paper as if it was included in Sympy already. Now I am stuck trying to use the represent method on the resulting density operator to find out whether i can represent it in a nicer way using another basis state. I am trying to use represent on a matrix with basis=the two basis vectors, but it either throws exception or just outputs the input. how do I input a correctly formatted basis? The example in the docstrings uses an operator, but I do not have the corresponding operator just the basis kets/vectors. Ideas, anyone? (I am hoping that be posing a lot of questions and providing at least part of the answers here myself that this will serve as a guide for others) -Hans On 20 Sep., 16:30, Ondřej Čertík ondrej.cer...@gmail.com wrote: Hi Hans, On Tue, Sep 20, 2011 at 6:27 AM, Hans Harhoff Andersen hansharh...@gmail.com wrote: that's ok. I found a way around the problem for now by manually typing out explicitly what i mean. whenever the quantum folks take a look at this I'd also like to aks where the functions density and reduced_density are defined. (They are mentioned in the paper by Cugini) but I can't find them in the version of sympy I have 0.7.0 (I just downloaded the git version but I can't find it there either). Thanks for your interest. The best is to ask Brian about this. I already sent him an email yesterday, so let's wait a few days. Ondrej -- You received this message because you are subscribed to the Google Groups sympy group. To post to this group, send email to sympy@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. -- You received this message because you are subscribed to the Google Groups sympy group. To post to this group, send email to sympy@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. -- Brian E. Granger Cal Poly State University, San Luis Obispo bgran...@calpoly.edu and elliso...@gmail.com -- You received this message because you are subscribed to the Google Groups sympy group. To post to this group, send email to sympy@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.
Re: [sympy] Re: ipytex cont.
Kurt, Specifically what changes did you have to make to Basic. IPython allows you to register arbitrary print logic for any class without changing that class, so all of this should be possible without any changes to Basic or the rest of sympy. Are you able to use the latex that is generated by sympy's existing latex printer? If not, what changes do you have to make. Have you looked at IPython.extensions.sympyprinting? Cheers, Brian On Thu, Sep 1, 2011 at 6:32 PM, Aaron Meurer asmeu...@gmail.com wrote: (forgot to CC the original author) Aaron Meurer On Thu, Sep 1, 2011 at 7:31 PM, Aaron Meurer asmeu...@gmail.com wrote: Hi. I am forwarding this message, and all attachments, that was sent to me (with the author's permission). I don't have time to look at this now, so if others could play around with it, that would be awesome. The goal is to get seamless nice LaTeX printing with SymPy in the IPython qtconsole. Aaron Meurer -- Forwarded message -- From: Kurt Pagani pag...@scios.ch Date: Thu, Sep 1, 2011 at 6:52 PM Subject: ipytex cont. To: Aaron Meurer asmeu...@gmail.com Hi, let me come back to the simpy tex rendering in ipython. I couldn't leave it alone, so I tried out different things. My first idea was that the TeX object should be stored within the sympy object. Well, a bad idea, because the 'Basic' class has no init and is more or less read-only. Now I have found another solution using a cache dict and all works surprisingly simple. Meanwhile I was able to compile the ipython-qtconsole on Linux, so the code is tested on NT and SuSE Linux. There is some saved HTML output attached (Basics.html is from NT and Advanced.html from Linux), showing the features available in a self-explanatory way. To get it work (only if you like of course): 1) copy ipytex.py to sympy/printing 2) replace sympy/core/basic.py by the attached one. There is only one additional method inserted into the Basic class (after __repr__). The ipytex.py was rewritten and simplified (the mplib version is unusable with sympy - at least for the moment - so it's been abandoned). I've pasted a lot of sympy expressions into the qtconsole (from the intro and ODE) and all but the 'Matrix' rendered smoothly (see Basics.html near the end). Does Matrix not inherit from Basic? I'm quite happy with this hack for the moment. I think it shows more clearly the interrelations than the stuff I sent you earlier. BTW you can do with the code whatever you like. Regards Kurt Pagani -- You received this message because you are subscribed to the Google Groups sympy group. To post to this group, send email to sympy@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. -- Brian E. Granger Cal Poly State University, San Luis Obispo bgran...@calpoly.edu and elliso...@gmail.com -- You received this message because you are subscribed to the Google Groups sympy group. To post to this group, send email to sympy@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.
Re: [sympy] Re: TeX output in IPython qt 0.11
Aaron, On Thu, Aug 25, 2011 at 4:12 PM, Aaron Meurer asmeu...@gmail.com wrote: Actually, the author and I are currently discussing off list ways to get this to work by default (perhaps it should be brought on list). Yes, please do. I can definitely point in the right direction on the IPython side of things. To see how the printing works and how to get an image back to the frontend, have a look in IPython.extensions.sympyprinting. Cheers, Brian Aaron Meurer On Thu, Aug 25, 2011 at 8:52 AM, Hans Moser hans.mose...@gmx.at wrote: Hi Thank you for the answer. Meanwhile I had a conversation with the author who fed me with hopes but discouraged me from changing any core code. H.Moser -- NEU: FreePhone - 0ct/min Handyspartarif mit Geld-zurück-Garantie! Jetzt informieren: http://www.gmx.net/de/go/freephone -- You received this message because you are subscribed to the Google Groups sympy group. To post to this group, send email to sympy@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. -- You received this message because you are subscribed to the Google Groups sympy group. To post to this group, send email to sympy@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. -- Brian E. Granger Cal Poly State University, San Luis Obispo bgran...@calpoly.edu and elliso...@gmail.com -- You received this message because you are subscribed to the Google Groups sympy group. To post to this group, send email to sympy@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.
Re: [sympy] Re: sympy for Quantum Field Theory (QFT)
From the physics/quantum perspective, the gamma matrices are just
operators that act on states. For this type of thing the machinery in
sympy.physics.quantum would be perfect. Some of the things it would
provide:
* We already have abstract/symbolic states operators that behave like
they should.
* Everything can be defined symbolically, but states and operators can
be represented in a given basis.
* Symbolic commutation/antocommutation relationships can be defined.
* And more...
The best starting place is to look at how we handle spin in
sympy.physics.quantum.spin. I should note that we don't have a
symbolic trace operation, but that could be implemented quite easily.
Cheers,
Brian
2011/8/5 Ondřej Čertík ondrej.cer...@gmail.com:
On Fri, Aug 5, 2011 at 12:50 AM, cschwan csch...@students.uni-mainz.de
wrote:
Thank you for your answers!
Unfortunately, I do not have access to the book Alan mentioned (I
think of buying it, saw it before when searching for the subject).
Nevertheless, thank you for your PDF-file, I will have a look into it.
The example from Ondřej is looking very similar to what I am looking
for. However, I noticed that the gamma matrices are implemented by a
specific representation. In my opinion it would be better to treat
them fully symbolically in order to gain results for dimensional
regularized calculations, which alter the Clifford-identity to the
following:
\gamma^\mu \gamma^\nu + \gamma^\nu \gamma^\mu = (2-\epsilon) g^{\mu
\nu}
That's right. There are basically 2 approaches:
1) use some particular representation, and simply multiply all the
matrices and then take a trace
2) do things symbolically using the relations between the matrices
I decided to try 1), as it seemed to me, that it should work fine. But
the resulting matrix is quite a mess, so one would need to figure out
whether there is some good way to simplify the result.
As to 2), I think there the difficulty is in the fact, that one needs
to know which rules to apply and how. If you go this route, I would be
very interested if you manage to get it working.
I seriously think of implementing this functionality.
That would be really great. Whenever you have something, just let us
know on the list and we'll help you with git and patches. Or any other
question you might have.
Ondrej
--
You received this message because you are subscribed to the Google Groups
sympy group.
To post to this group, send email to sympy@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.
--
Brian E. Granger
Cal Poly State University, San Luis Obispo
bgran...@calpoly.edu and elliso...@gmail.com
--
You received this message because you are subscribed to the Google Groups
sympy group.
To post to this group, send email to sympy@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.
Re: [sympy] Avoiding big branches
But all of the technical details about merging and rebasing aside, I completely agree that huge branches should be avoided whenever possible. Cheers, Brian 2011/7/26 Ondřej Čertík ondrej.cer...@gmail.com: On Tue, Jul 26, 2011 at 1:48 PM, Aaron Meurer asmeu...@gmail.com wrote: Basically, it was like this: Mateusz had his polys branch, which had all his polys fixes. Every time Mateusz wanted to be up to date with master, he rebased, and created a new branch, polys2, polys3, etc. My branch from the start, integration, was based on one of these polys branches. Then, when I wanted an update from one of the polys branches, I would rebase over the newest polysn and renumber my branch, integration2, and then integration3. But at this point, I realized that rebasing is bad, and I should really not be doing it. So from that point on, I have never rebased the branch. This is why my branch is called integration3 instead of just integration, btw. Probably if I had been rebasing over master instead of merging, this would have been easier. But it would have been a false sense of easy. This is because only half of the problems came from merge conflicts. Other things were changes in the code. For example, as_basic was renamed to as_expr. If I had rebased my branch over maser, not a single commit in my history would have worked any more, because they all use as_basic. So my choices would have been: 1. Go back and fix each commit in the history so that the tests pass. This would have been even *harder* than the merge, I think. 2. Have a branch were bisecting is basically impossible. Another problem with rebasing is that sometimes changes are rebased out, so you are left with commits that no longer change what they say that change. I have commits like this in my branch, from when I was rebasing. For example, https://github.com/asmeurer/sympy/commit/4fbc80c12aae45f3a95e05740b62c4d546ada337, which is from my original integration branch, does what it says, it adds a check for the Python version. But this was backported to master since my integration3 rebase, so now the corresponding commit 2ffedb50a3e0a4ae274d117ef87e09834ff8c98b looks confusing, because the part that does what the commit message says was rebased out. We also see the problems of rebasing from the original polys merge (not polys12, but the very first new polys branch). There are a bunch of commits near the beginning of that branch for which sympy does not import; you may have noticed these if you've tried bisecting back that far. No doubt these worked originally, but the rebase broke them somehow. This is why I believe you when you say your longest *rebase* was 1h or work, because rebasing is easier in the sense that it hides these problems from you. How long would it have taken if you had done the right thing and merged instead? My branch was messy, so I didn't want to have it just merged. Also, I realized, that I think at one occasion, it took me more like 2h. Still though, not a big deal. From what you say, I think that the conclusions are clear: 1) Mateusz should have just kept merging, and you should have kept merging to his branch. 2) The only time rebase is allowed is on your private branch, that nobody is using (yet). There is also another big problem --- when reviewing pull request, some people just rebase everything, and there is no way for me to check what changes they actually made. I think that a better practice is to do the best and submit a good solid pull request. And then just keep adding patches. (Unless it's so screwed up, that a good nice rebase is appropriate, for example when one is new to git, and one should do it at the end of the review, if nobody is using that branch yet) Ondrej -- You received this message because you are subscribed to the Google Groups sympy group. To post to this group, send email to sympy@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. -- Brian E. Granger Cal Poly State University, San Luis Obispo bgran...@calpoly.edu and elliso...@gmail.com -- You received this message because you are subscribed to the Google Groups sympy group. To post to this group, send email to sympy@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.
Re: [sympy] Re: Matrix Symbol
Matthew,
Arron has provided a fantastic summary of the issues involve. The
summary is that even if you subclass Add/Mul/Pow, sympy will end up
creating expressions that don't use your subclasses everywhere. This
can't be fixed without changing the core, which is outside the scope
of your project. I know I sound like a broken record, but you should
resist the temptation to define your own Add/Mul/Pow classes.
Cheers,
Brian
On Tue, Jul 12, 2011 at 10:25 PM, Aaron Meurer asmeu...@gmail.com wrote:
One thing that I have noticed with regard to overriding __mul__ and
__rmul__ (for example) is that you can never completely control what
happens to your class because of association. For example, suppose
that A and B are MatrixExprs and x is some Expr object (say, a
Symbol). Suppose that A*B should give a ShapeError, and that x is a
scalar, which does not matter where it is in the expression. Then you
have to program it so that all of the following give ShapeError:
1. x*(A*B)
2. (x*A)*B
3. (A*x)*B
4. A*(x*B)
5. (A*B)*x
6. A*(B*x)
Let us look at these. Obviously, 1 and 5 will work, since you have
complete control over A.__mul__(B). Similarly, in 4 and 6, you will
end up with A.__mul__(Mul(x, B)), but this is not a problem, since you
can make A.__mul__ check for the left-most noncommutative in a Mul.
But what about 2 and 3? Here, we have __mul__ being called by a Expr
type, namely, Mul(x, A). You want to get B.__rmul__(Mul(x, A)), since
you have implemented shape checking logic in MatrixExpr.__(r)mul__.
But b.__rmul__(a) is called with a*b only if a.__mul__(b) returns
NotImplemented. So, basically, we need Mul.__mul__(MatrixExpr) to
return NotImplemented. Well, let us look at the code for Mul.__mul__
(actually Expr.__mul__):
@_sympifyit('other', NotImplemented)
@call_highest_priority('__rmul__')
def __mul__(self, other):
return Mul(self, other)
Well, this is not very helpful, because the logic is buried in some
decorators. So let us look at the code for those decorators. I will
not bore you by pasting the entire code here (you can see it in
sympy/core/decorators.py), but basically, _sympifyit makes tries to
sympify other, and makes __mul__ return NotImplemented if it fails. I
am not delving into this, because sympify would not fail for
MatrixExpr (otherwise, we would actually have a problem doing any form
of x*A*B).
So call_highest_priority seems to be a better bet. This decorator I
will also not paste here, but it basically lets you define
._op_priority on your object, and if it is greater than Expr's (which
is quite arbitrarily set to 10.0), then it will call
other.__rmul__(self).
But wait, there's more. _op_priority can make the above cases work,
but * is not the only way that SymPy multiplies things. You will also
have to deal with variations on Mul(x, A, B). Mul completely ignores
_op_priority. Unfortunately, even if this may seem like a more
esoteric way to multiply things that you can just recommend users
avoid, it is used internally a lot, because Mul(*args) is more
efficient than reduce(operator.mul, args).
Thus, you see that it is quite impossible to make things work 100% of
the time without modifying the core. And actually, because of the Mul
thing that would not work at all and that is called by so many core
functions and methods, you will not even get something like things
working 90% of the time, but instead things will break when used a
certain way, and you will have hard to track bugs.
Aaron Meurer
On Tue, Jul 12, 2011 at 3:08 PM, Matthew Rocklin mrock...@gmail.com wrote:
Subclassing Expr has some issues as well. This is what Brian was referring
to. Within all of our code we use Add and Mul and don't check if instead we
should use some subclass of Add or subclass of Mul. If I feed a matrix
expression into these objects then the special matrix structure is lost.
This happens if, for example, you call simplify on a matrix expression.
I think I can get around this though with a few well placed matrixify
functions. Matrixify is a function which goes through the expression tree
and makes appropriate fixes. I've had good success so far with a very very
basic Matrixify function.
Brian, did you have particular horror stories trying to subclass Expr? I'm
enthusiastic about my approach but you seemed to have a bad experience. Can
you suggest difficult test cases that I should think about?
On Fri, Jul 8, 2011 at 3:22 PM, Aaron Meurer asmeu...@gmail.com wrote:
On Fri, Jul 8, 2011 at 4:00 AM, SherjilOzair sherjiloz...@gmail.com
wrote:
There is something I'm doing as part of my project which maybe be
useful. I'm implementing a Matrix_ wrapper class which will wrap over
low-level matrices. Its being written to replace the current Matrix
class. Algorithmic code and user-level code is being separated into
different classes. Currently, we have three internal matrices, the
DenseMatrix( a modified
Re: [sympy] Re: Matrix Symbol
Matthew,
On Wed, Jul 13, 2011 at 6:39 AM, Matthew Rocklin mrock...@gmail.com wrote:
I have op_priority set to 11 so that basic arithmetic operations do use
MatMuls and MatAdds. MatMul and MatAdd check shape, then call regular
Mul/Add __new__ methods to take advantage of the already built flattening
functions. After that's done they go through and change classes back to
MatMul/MatAdd in case a normal Mul/Add was called within the __new__. So far
this has worked very well. All of the associativity cases 1-6 throw the
correct error. The more complex expressions that I've tried have also worked
fine.
Calling Mul or Add explicitly does break things. There's no entry point for
me to insert clever logic as I don't want to edit core functions. My
solution here is simply to say Use MatMul or MatAdd instead, or, if you
must use Mul/Add, call matrixify on the expression afterwards. Matrixify
will be guaranteed to return a Matrix expression if MatrixSymbols exist
within a normal Expression. I plan to put it in a few key functions like
simplify and expand.
Is this matrixify solution too much of a hack? Hopefully I can hide it away
within a few key functions so that the user never needs to know about it
unless they explicitly use Add or Mul. If they're using Add or Mul then I
expect them to be clever enough to handle matrixify.
I'm working on this branch .
As I understand it Matrixify goes through an expression and makes sure
that your Mul/Add/Pow subclasses are used. If that is the case, I
advise against it because the second a user starts to do things with
the expression they will have to call Matrixify again. Again, I would
just use the default Mul/Add/Pow and provide standalone functions like
check_shape that perform a specific type of action on an expression.
Cheers,
Brian
On Wed, Jul 13, 2011 at 12:25 AM, Aaron Meurer asmeu...@gmail.com wrote:
One thing that I have noticed with regard to overriding __mul__ and
__rmul__ (for example) is that you can never completely control what
happens to your class because of association. For example, suppose
that A and B are MatrixExprs and x is some Expr object (say, a
Symbol). Suppose that A*B should give a ShapeError, and that x is a
scalar, which does not matter where it is in the expression. Then you
have to program it so that all of the following give ShapeError:
1. x*(A*B)
2. (x*A)*B
3. (A*x)*B
4. A*(x*B)
5. (A*B)*x
6. A*(B*x)
Let us look at these. Obviously, 1 and 5 will work, since you have
complete control over A.__mul__(B). Similarly, in 4 and 6, you will
end up with A.__mul__(Mul(x, B)), but this is not a problem, since you
can make A.__mul__ check for the left-most noncommutative in a Mul.
But what about 2 and 3? Here, we have __mul__ being called by a Expr
type, namely, Mul(x, A). You want to get B.__rmul__(Mul(x, A)), since
you have implemented shape checking logic in MatrixExpr.__(r)mul__.
But b.__rmul__(a) is called with a*b only if a.__mul__(b) returns
NotImplemented. So, basically, we need Mul.__mul__(MatrixExpr) to
return NotImplemented. Well, let us look at the code for Mul.__mul__
(actually Expr.__mul__):
@_sympifyit('other', NotImplemented)
@call_highest_priority('__rmul__')
def __mul__(self, other):
return Mul(self, other)
Well, this is not very helpful, because the logic is buried in some
decorators. So let us look at the code for those decorators. I will
not bore you by pasting the entire code here (you can see it in
sympy/core/decorators.py), but basically, _sympifyit makes tries to
sympify other, and makes __mul__ return NotImplemented if it fails. I
am not delving into this, because sympify would not fail for
MatrixExpr (otherwise, we would actually have a problem doing any form
of x*A*B).
So call_highest_priority seems to be a better bet. This decorator I
will also not paste here, but it basically lets you define
._op_priority on your object, and if it is greater than Expr's (which
is quite arbitrarily set to 10.0), then it will call
other.__rmul__(self).
But wait, there's more. _op_priority can make the above cases work,
but * is not the only way that SymPy multiplies things. You will also
have to deal with variations on Mul(x, A, B). Mul completely ignores
_op_priority. Unfortunately, even if this may seem like a more
esoteric way to multiply things that you can just recommend users
avoid, it is used internally a lot, because Mul(*args) is more
efficient than reduce(operator.mul, args).
Thus, you see that it is quite impossible to make things work 100% of
the time without modifying the core. And actually, because of the Mul
thing that would not work at all and that is called by so many core
functions and methods, you will not even get something like things
working 90% of the time, but instead things will break when used a
certain way, and you will have hard to track bugs.
Aaron Meurer
On Tue, Jul 12, 2011 at 3:08 PM, Matthew Rocklin
Re: [sympy] Re: Matrix Symbol
On Wed, Jul 13, 2011 at 11:19 AM, Ronan Lamy ronan.l...@gmail.com wrote: Le mercredi 13 juillet 2011 à 10:51 -0700, Brian Granger a écrit : Matthew, Arron has provided a fantastic summary of the issues involve. The summary is that even if you subclass Add/Mul/Pow, sympy will end up creating expressions that don't use your subclasses everywhere. This can't be fixed without changing the core, which is outside the scope of your project. I know I sound like a broken record, but you should resist the temptation to define your own Add/Mul/Pow classes. I'm not convinced. What other solution is there? For now just don't do it. The quantum stuff is equally complicated as the matrix symbols stuff (in fact from a mathematical perspective, they are fomally equivalent) and we are surviving just fine without it. Last summer we started out by subclassing Add/Mul/Pow for the quantum stuff. For weeks we kept finding things that were broken. It was horrible and we realized that i) we would end up rewriting much of sympy and 2) it would still be fundamentally broken. Once we gave up on that are just used sympy Mul/Add/Pow we started to move 10 times faster and had very few problems. We did have to give up on our grand visions of doing custom logic in Mul/Add/Pow, but we have moved that logic into standalone functions. Those functions are quite simple though and work just great. Also, creating Add/Mul/Pow subclasses looks like the obvious way of extending sympy, so we want to make it work at some point. Creating MatrixAdd, etc. will help a lot with that by highlighting all the places where we assume things like a + b == Add(a, b). So if Matthew thinks he can make it work without too much pain, compared to the alternatives, then I think he should go for it. It is not at all obvious to me that the model should be that Add/Mul/Pow subclasses are encouraged. I think a much better approach would be closer to what Mathematica has, where objects can define rules that are applied when the objects are multiplied. IOW, Mul/Add/Pow themselves should have extension APIs, but those extension APIs should not be handled through subclassing. But again, this is a very difficult problem and it is not clear to me what the solution is. In either case, I stlll feel it is beyond the scope of the current work. Cheers, Brian -- You received this message because you are subscribed to the Google Groups sympy group. To post to this group, send email to sympy@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. -- Brian E. Granger Cal Poly State University, San Luis Obispo bgran...@calpoly.edu and elliso...@gmail.com -- You received this message because you are subscribed to the Google Groups sympy group. To post to this group, send email to sympy@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.
Re: [sympy] Improving subs (issue 2026)
As many of you may know, the main thing blocking the merge of my work on the Risch algorithm (see my integration3 branch) is not any deficiency in the algorithm, though there are several parts that are still not implemented, but the lack of a so called atomic substitution framework. The relevant issue here is 2026 (http://code.google.com/p/sympy/issues/detail?id=2026). Basically, the following breaks the preprocessing code in risch_integrate: In [1]: exp(2*x).subs(exp(x), y) Out[1]: 2 y I need a way for subs to behave exactly, so the above would return exp(2*x). Thus, I have disabled this completely in my integration3 branch, but this is only a temporary solution, as there is a lot of code that relies on this behavior (especially in the series/limits code), and it would be a regression anyway. I have always thought that subs should not know about any mathematical relationships, but should behave as you are proposing (atomic or exact=True). In my mind, subs is a foundation that can be used to build more advanced pattern matching and rule capabilities. But those more advanced rules (such as done by power) should be in subs itself, but in that higher level. Thus. I am +1 on the exact or atomic keyword to subs (I prefer exact). I am ++1 on having that be the default behavior Cheers, Brian So there needs to be a way to do exp(2*x).subs(exp(x), y, atomic=True) exp(2*x) Now, as it turns out, it has come up in other places that people want control over the way that subs works in other ways. In the issue, I talk about something called integer_powers, which would work like exp(2*x).subs(exp(x), y, integer_powers=True) y**2 exp(x).subs(exp(2*x), y, integer_powers=True) exp(x) In other words, it does not do power manipulation in the replacement unless the resulting power is an integer. This is needed in some places such as the heurisch algorithm to ensure that the resulting expression will be a polynomial (actually, a rational function) in the substitution variable. In addition, there is also some concern about the assumptions validity of certain algebraic substitution rules. See issues 2081 and 2552. So in the interest of doing this right, I think there needs to be some kind of hints mechanism to subs. My question is, what do you think would be the best way to implement this? Presently the expand function has something like this, but I'm not really convinced that the way that it's implemented is a very good one. Here's (roughly) the way that subs works now: Basic defines two methods, .subs and ._eval_subs. Basic.subs() is of course the user level function that everyone calls, and pretty much no subclass of Basic overrides it. The actual substitution happens in ._eval_subs, which is also responsible for recursing the substitution down the .args. Basic has a simple implementation, but most classes end up overriding it (for example, exp has overridden it to allow the above fancy algebraic substitution). What's the best way to implement the various hints I want to add to .subs()? A few things to take into consideration: - .expand() works, as I mentioned earlier, by having ._eval_expand_hint() methods. I don't think this is the best way, so that's why I'm asking here to see if anyone has any better ideas. - It should remain backwards compatible with any class that defines ._eval_subs(self, old, new). Unfortunately, there wasn't much foresight when this was originally designed, so the protocol does not call for any *args or **kwargs. However, that doesn't necessarily weigh those options out, as we could easily make Basic.subs() check for an old style definition and ignore hints in that case. - I haven't looked at it, but we might be able to implement at least atomic substitution entirely in Basic (no class need override any methods to get it to work). This is because it is so simple that the default agnostic method might be able to do it entirely. The rule for atomic substitution by the way is that expr.subs(old, new, atomic=True) should replace old with new in expr if and only if old is in expr.atoms(old.__class__). So I'm open to any ideas on how to implement this, API-wise. Also, Chris, did you start this at all in any of your branches and/or are you willing to help with this? Aaron Meurer -- You received this message because you are subscribed to the Google Groups sympy group. To post to this group, send email to sympy@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. -- Brian E. Granger Cal Poly State University, San Luis Obispo bgran...@calpoly.edu and elliso...@gmail.com -- You received this message because you are subscribed to the Google Groups sympy group. To post to this group, send email to sympy@googlegroups.com. To unsubscribe from this group,
Re: [sympy] Re: Matrix Symbol
On Sun, Jul 3, 2011 at 1:41 PM, Matthew Rocklin mrock...@gmail.com wrote:
It looks like the assumptions system would be a good place for the fancy
matrix questions (positive definite, invertible, etc...). I'm not sure that
it's appropriate for shape though.
I'm going to boldly propose that we add shape as a property to the core Expr
class. It won't be checked as operations happen (to optimize speed for the
common non-matrix case) but will be computed on demand and raise errors at
that time if things are misaligned. I might also push for a is_Matrix flag.
i.e.
I am -1 on putting shape into Expr itself. It is too specialized to
be there. It should only be in the classes that actually have shape
information. I agree though that we need to enhance sympy to know
about such things, but that logic type of logic should be in Mul and
should not be narrowly focused on shape but should include the
handling of all types that need custom logic upon multiplication.
As I have said before, I would forget about shape checking *entirely*
at this point in the game though so you can focus on the more
interesting and relevant aspects of this work. Once sympy is extended
in the right way, you will get shape checking almost for free...
Cheers,
Brian
A = MatrixSymbol('A', 3, 4)
B = MatrixSymbol('B', 4, 7)
C = 2*A*B # Nothing matrix-y happens here
C.shape # Shape is checked here
(3, 7)
D = 1 + B*A # This passes even though it's invalid
D.shape # Error is found when asking for the shape
ShapeError(
print Symbol('x').shape # Normal expressions have no shape
None
I don't think this will affect computation at all for non-matrix situations.
It adds a minimal amount of code complexity to the Add, Mul, Pow, etc...
classes.
I'm going to write something up for review later tonight. Please someone
stop me if this is a poor idea.
On Thu, Jun 30, 2011 at 6:14 PM, Aaron Meurer asmeu...@gmail.com wrote:
There's some info at http://docs.sympy.org/0.7.0/modules/assumptions.html.
Aaron Meurer
On Thu, Jun 30, 2011 at 12:35 PM, Ronan Lamy ronan.l...@gmail.com wrote:
Le jeudi 30 juin 2011 à 13:25 -0500, Matthew Rocklin a écrit :
Where is the best place to read about the new assumptions system?
I'm afraid that the best place is the source code in sympy/assumptions/.
I'm not aware of any comprehensive and current write-up on the new
assumptions.
On Thu, Jun 30, 2011 at 1:18 PM, Aaron Meurer asmeu...@gmail.com
wrote:
On Thu, Jun 30, 2011 at 7:17 AM, Matthew Rocklin
mrock...@gmail.com wrote:
I agree that support for derivatives on matrices is
important; I would like
this myself. I haven't thought much about it in the context
of SymPy before
though so thank you for bringing it up.
I haven't solidified my understanding of this problem but it
seems like
there are a few concepts of a derivative here.
Given a matrix expression we can differentiate with respect
to the various
matrices themselves. This is likely very similar to Aaron's
example using
stock SymPy with non-commutative symbols. This should (I
think) work out of
the box
Given a function on vector valued inputs with possible
vector valued outputs
we can define directional derivatives. I think this is what
Alan is talking
about. In this situation the objects can easily become high
rank (Hessians
of vector-valued functions are not matrices). This leads me
to the idea that
we should consider mathematical Tensors rather than
matrices.
The tensor vs matrix issue makes me nervous. There is a lot
of special stuff
happening on rank two tensors (matrices) that we rarely care
about at higher
ranks. Maybe this work should be done on a Tensor class and
Matrices should
subclass Tensors? This is getting beyond the scope of what I
was looking for
with a Matrix Symbol. I probably won't pursue this
enhancement in the near
future but would be happy to support someone else's effort.
For the moment I'm not working on Matrix Expressions
actually. I'm a bit
stuck on how to proceed and would welcome any
suggestions. The best idea I
have now is to insert symbols into standard sympy Exprs and
have aspects
like shape and is_invertible be functions which are called
on the Expr tree
rather than fields or methods of the object. This will fail
to raise
exceptions when illegal operations are performed but should
get the job
done. The Indexed class is somewhat similar in flavor.
This is something that you
Re: [sympy] Re: MathJax for the Sphinx docs
We are using MathJax for the new IPython notebook and it is really great, so I think this would be a good move. Is there anyway of getting latex output in the sympy code samples? Cheers, Brian On Thu, Jun 30, 2011 at 11:11 PM, Aaron Meurer asmeu...@gmail.com wrote: I just tried this on my iPod touch, and it works. It takes a little while to render the math, due to the slower processor, but once it does, it's worth it, because it's way crisper when you zoom in, which you tend to do a lot on these mobile devices with their small screens. And anyway, like I said, you can at least see the LaTeX math while you're waiting for it to render, which is readable. Aaron Meurer On Thu, Jun 30, 2011 at 11:55 PM, Aaron Meurer asmeu...@gmail.com wrote: I've made this easer for people who just want to play around with what it looks like by pushing a demo up to docs.sympy.org. Go to http://docs.sympy.org/mathjax/ and navigate to a LaTeX intensive page (the mpmath function pages are good examples). Then compare against the same page replacing mathjax in the url with dev. You can see on some pages there are errors (yellow boxes). For example, at http://docs.sympy.org/mathjax/modules/galgebra/GA/GAsympy.html. This is because they are somehow defining custom control sequences. I haven't figured out how to make these work with MathJax yet. I want to see if people like this idea before I try anything further. By the way, the built mathjax docs are 7.3 MB, whereas the built docs using the current method are 13 MB. Aaron Meurer On Thu, Jun 30, 2011 at 11:43 PM, Aaron Meurer asmeu...@gmail.com wrote: Hi. I just discovered how to use MathJax in our Sphinx docs, and it's really easy. You just have to copy a file to the doc/src directory and make a couple of changes to the conf.py file. I have done this at my mathjax branch (https://github.com/asmeurer/sympy/tree/mathjax). More information (also in the commit message): See https://bitbucket.org/kevindunn/sphinx-extension-mathjax/wiki/Home and https://groups.google.com/forum/#!msg/sphinx-dev/SkLZlqapcM8/tI2qk5uTY3gJ. MathJax renders the LaTeX equations in the browser. This has several advantages: - Compiling the Sphinx docs from scratch is *way* faster, since it doesn't have to compile the LaTeX images. Previously on my machine, it took about half an hour to compile from scratch (mainly due to heavy LaTeX use in the mpmath docs). Now it only takes a couple of minutes. - Because no LaTeX images are stored, the overall size of the compiled docs is smaller. - The rendered math in the browser is selectable (which also means it's searchable), and crisp at arbitrary zoom levels, since it renders the math using actual fonts, not images. So it's just like an equation in a regular LaTeX pdf document. - You can right click on the equation and get a menu that will show the source. As a side benefit, you can also use this to convert the LaTeX to mathml. - No changes are required in the source files. This uses the same :math: pragma as the previous system, so it's very swappable. - This currently uses an online version of the mathjax.js file that is free to use for production, but this can easily be downloaded and used locally for offline use. Disadvantages: - You will not be warned about LaTeX errors at doc compile time. The only way I know to find them is to look at all the rendered html files for yellow MathJax error boxes. Perhaps there is a more streamlined way to do this, though. - There currently are some errors in the GA docs, due to some strange control sequences like \W and \lbrk. I'm not sure where these are defined, but this will have to be fixed if we use this. - Your browser has to render the math at load time, which makes it a little slower for LaTeX intensive pages. Actually, it isn't too bad. And it seems to render from the top down, so you can see the math at the top almost immediately. And while it is rendering, you see the LaTeX source, so you can at least read it. To compare this against the old system checkout my branch and, do cd doc make clean # To clear the old docs make html And open a LaTeX intensive page like _build/html/modules/mpmath/functions/hypergeometric.html in your browser and compare it against the current page at docs.sympy.org (in this case, http://docs.sympy.org/0.7.0/modules/mpmath/functions/hypergeometric.html#mpmath.hyp0f1). Note how with the MathJax, you can select parts of the math equations, you can zoom in (using your browser's zoom functionality) without any loss of resolution, and you right click on the equation to get the source. Aaron Meurer -- You received this message because you are subscribed to the Google Groups sympy group. To post to this group, send email to sympy@googlegroups.com. To unsubscribe from this group, send email to sympy+unsubscr...@googlegroups.com. For more options, visit this group at
Re: [sympy] Re: Matrix Symbol
Matthew, I *strongly* recommend against subclassing Mul/Pow/Add as you will find that it is *impossible* even with op_priority to have your Mul/Pow/Add used all of the time. In a variety of contexts, you will *want* your subclasses to be used, but sympy's base Mul/Add/Pow will be used. There is no way to prevent this with the current design. Just use the sympy's existing Mul/Add/Pow and live with its limitations for now. Cheers, Brian On Tue, Jun 28, 2011 at 9:00 AM, Matthew Rocklin mrock...@gmail.com wrote: There is a barebones implementation of a Matrix Expression class here: https://github.com/mrocklin/sympy/tree/matrix_expr/sympy/matrices Comments/criticism welcome. On Mon, Jun 27, 2011 at 10:08 PM, Aaron Meurer asmeu...@gmail.com wrote: Option 3 might work. You should talk to Brian Granger about the advantages and disadvantages of defining your own Expr objects, as that's what is done in the quantum code. Note that you should be able to handle the other stuff with the assumptions (in theory anyway; assumptions are kind of a mess right now, so I couldn't say how well it would work). But even if we fix the core and option 1 becomes feasible, the code can be refactored, so if you want something now, I am +1 to trying option 3. I would rather prefer to avoid option 2, unless you are going to fix it in a more general way (like issue 1941). Aaron Meurer On Mon, Jun 27, 2011 at 8:32 PM, Matthew Rocklin mrock...@gmail.com wrote: Yeah, definitely. I must confess that a hidden passion of mine is optimizing linear algebra (we all have our quirks). I was just looking at Theano a minute ago actually - I think it would be cool to easily dump Matrix expressions onto them. How should matrix expressions be represented in SymPy though? The way I see it there are three options Leave it as a SymPy Expr, forget shape, transpose, rank, etc... for now. Maybe future SymPy elegance will make clever things possible (such as issue 1941) Enhance SymPy Expr's to play nice with Matrices Subclass a family of MatrixExpr classes that live outside the core Probably there are things I'm missing but this is how I separate things. Because I'd like this done sooner rather than later I'm obviously in favor of 2 or 3 with a preference for 3. I don't know enough about SymPy however to tell whether this is the right way and I'd rather not work on something unless it has a chance at getting in. I'll push again for three by saying that there is a lot going on in Matrix Expressions other than just non-commutativity and shape. Inverses, transposes, rank, symmetry, positive_definiteness, conditioning, etc... all play a big role in computational decisions made on matrices. Additionally matrix expressions are ubiquitous and important in the scientific computing world. From my (strongly biased) perspective they deserve special treatment. But for my Summer project I just need something. Even 1 might work for me. Does anyone have any thoughts or suggestions? Best, -Matt On Mon, Jun 27, 2011 at 9:07 PM, Aaron Meurer asmeu...@gmail.com wrote: Unless you can make matrices sympifyable, you probably won't be able to use .subs. That isn't to say that you can't write your own specialized function to do the substitution. There's also some cool stuff you could do here, like implementing a matrix chain multiplication algorithm (http://en.wikipedia.org/wiki/Matrix_chain_multiplication) to compute the most efficient way to multiply a product of matrices ABCD... Aaron Meurer On Mon, Jun 27, 2011 at 9:54 AM, Matthew Rocklin mrock...@gmail.com wrote: Regarding expr.subs(x,matrix): This is tricky because Matrices aren't sympifiable. I think you would need to substitute all matrix symbols for matrices at once and then turn the expression into a Matrix object using the Matrix.__add__ etc methods. Or maybe any substituted Matrix would become some sort of ImmutableMatrix object so that it could live inside an Expr. Regarding other differences: Being able to substitute computational elements like Matrices/SparseMatrices/LinearOperators into matrix expressions is definitely the main motivating application behind symbolic matrices. This is not my major focus right now though. I'm focusing on turning statistical statements into computational ones. I've been generating integrals for a while now and would like to start generating Matrix Expressions like what's found here. Being able to check the shape of an expression is likely going to be useful for me. I suspect that there will be more features of matrices that I'd like exposed other than just that they're not commutative. Knowing if it is invertible or not is a good example. Of course, after I generate and simplify these expressions I'll need to substitute in actual matrices of some form
Re: [sympy] Problem with evaluating rotation operator
I know this has already been merged, but I wanted to say that this as well as the other PR that was merged look extremely good. The test coverage is fantastic and will give us a super-solid foundation to build everything else on. Great work! On Wed, Jun 22, 2011 at 5:39 PM, Ondrej Certik ondrej.cer...@gmail.com wrote: On Wed, Jun 22, 2011 at 1:02 AM, Sean Vig sean.v@gmail.com wrote: Hi everyone, I have currently implemented the improved Wigner d matrix method and included tests for this, the Wigner D function and the rewrite and represent functions which are improved in this pull request. If anyone could do any final testing and review, I'd appreciate it. Thanks. https://github.com/sympy/sympy/pull/431 I merged it in, thanks! Ondrej -- You received this message because you are subscribed to the Google Groups sympy group. To post to this group, send email to sympy@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. -- Brian E. Granger Cal Poly State University, San Luis Obispo bgran...@calpoly.edu and elliso...@gmail.com -- You received this message because you are subscribed to the Google Groups sympy group. To post to this group, send email to sympy@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.
Re: [sympy] Test failure in 0.7.0 pysics.quantum.matrixcache
Hi, Just returned from being out of town for 4 days. I will try to get caught up on sympy things tomorrow. Brian On Sun, Jun 19, 2011 at 10:42 PM, Aaron Meurer asmeu...@gmail.com wrote: The way the quantum code is written, it's not very easy to disable numpy globally. I could do it, but it would require copying the same four lines checking the system version and emitting a warning in the half dozen files that import numpy. So, to fix this right, I need advice from Brian and others who know the quantum code. Where would be the best place to put some kind of global parameter defining if numpy is supported for the quantum code (similar to what the polys use for gmpy)? Aaron Meurer On Sun, Jun 19, 2011 at 8:38 PM, Aaron Meurer asmeu...@gmail.com wrote: OK, this is definitely a bug in numpy (or Python). I created a file numpyfloattest.py with the following contents: import numpy class A(object): def __float__(self): return 2.0 def __complex__(self): return 5.0j a = A() print numpy.matrix([[a]], dtype='complex') And ran: Aaron-Meurer:sympy aaronmeurer(0.7.0$%)$python2.5 numpyfloattest.py [[ 2.+0.j]] Aaron-Meurer:sympy aaronmeurer(0.7.0$%)$python2.7 numpyfloattest.py [[ 0.+5.j]] So for some reason, in Python 2.5, it runs complex(float()) on the data. Of course, this doesn't work very well if the numbers are complex, like sympy.I. I have created http://projects.scipy.org/numpy/ticket/1872 for this. In the meanwhile, I will just disable numpy in the quantum code in Python 2.5. Aaron Meurer On Sun, Jun 19, 2011 at 8:04 PM, Aaron Meurer asmeu...@gmail.com wrote: I think I have a lead. In numpy 1.6, this instead gives numpy.matrix([[0, I]], dtype='complex') Traceback (most recent call last): File stdin, line 1, in module File /Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/numpy/matrixlib/defmatrix.py, line 257, in __new__ arr = N.array(data, dtype=dtype, copy=copy) File sympy/core/expr.py, line 129, in __float__ raise ValueError(Symbolic value, can't compute) ValueError: Symbolic value, can't compute in Python 2.5 (and it works in Python 2.6 and 2.7). So I guess the bug is in SymPy somewhere, and numpy 1.5 was catching that ValueError and re-throwing it as a TypeError. Aaron Meurer On Sun, Jun 19, 2011 at 7:39 PM, Aaron Meurer asmeu...@gmail.com wrote: On Sun, Jun 19, 2011 at 7:32 PM, Aaron Meurer asmeu...@gmail.com wrote: I don't know much about numpy, so this one has me stumped. For some reason numpy.matrix([[0, I]], dtype='complex') fails in Python 2.5 (with the above error), but not in Python 2.6 or 2.7 (I is sympy.I). Can someone with numpy knowledge give any insight here? Otherwise, I think the solution might have to be to disable numpy support in the quantum code in Python 2.5. I haven't looked at why it kills the test runner yet. I'll look at that now. Oh, this is rather obvious. It's because the exception is raised at import time. If it were raised when running an actual test, it would be caught by the test runner. This is probably OK behavior (anyway, it's not top priority to change it). Aaron Meurer By the way, a workaround might be to do np.matrix([map(complex, i) for i in m.tolist()], dtype=complex), i.e., manually convert the elements of the Matrix to complex, but this is rather hackish and I would prefer to aviod it if possible. Aaron Meurer On Sun, Jun 19, 2011 at 5:36 PM, Aaron Meurer asmeu...@gmail.com wrote: Thanks for reporting this. It seems you've uncovered two bugs (the second one is that the error killed the test runner). I'll see if I can figure out how to fix at least the numpy one for the release. Do you know how to fix it? If so, please send a pull request. Aaron Meurer On Sat, Jun 18, 2011 at 1:03 PM, Ted Horst ted.ho...@earthlink.net wrote: I'm a little late to the party, but I just tested 0.7.0 tip and got this error (stopped testing): This is with python 2.5.1, numpy 1.5.0, no scipy, no gmpy on OSX 10.5.8 PPC (big endian). I can get the error from just importing sympy.physics.quantum.matrixcache. It makes sense because we are passing sympy.I with dtype 'complex' to numpy. Ted Traceback (most recent call last): File setup.py, line 269, in module 'audit' : audit, File /System/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/distutils/core.py, line 151, in setup dist.run_commands() File /System/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/distutils/dist.py, line 974, in run_commands self.run_command(cmd) File /System/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/distutils/dist.py, line 994, in run_command cmd_obj.run() File setup.py, line 161, in run if sympy.test(): File sympy/utilities/runtests.py, line 181, in test return t.test(sort=sort) File sympy/utilities/runtests.py, line 487, in test
Re: [sympy] Problem with evaluating rotation operator
Ondrej, On Thu, Jun 16, 2011 at 11:12 PM, Ondrej Certik ondrej.cer...@gmail.com wrote: On Thu, Jun 16, 2011 at 9:27 PM, Brian Granger elliso...@gmail.com wrote: Sean, Here are some notes I sent to you earlier in the summer. The points made here are quite important.. So there are some things you should know about the Wigner D matrix: * While I implemented it, I have 0 confidence that the current implementation is free of bugs. Because of this, one of the first tasks should be to test this part of the code extensively, both for numerical and symbolic arguments. I would test the D and d matrix code thoroughly *before* moving on to anything else. It would be great to see a pull request for that. * The current method of computing the D matrix is not optimal. This is because we probably want to use a different form for the integer and half integer spin values. This is to get the canonical forms where, for 1/2 integer spins there are things like sin(theta/2) and cos(theta/2), but for integer spins, sin(theta) and cos(theta) appear. This should be implemented and then tested extensively. This will also help in testing and comparing to the tables in Varsh. * Let's use the convention of Varshalovich for the D-matrices. He follows the convention of most of the other main people in the field (see Table 4.2 for a list). * We should use his convention for Euler angles as well. * Because of the intimate relationship between CG, Wigner 3j6j, etc and the rotation matrices, we probably want to have a symbolic DMatrix class that we can use when we are representing various sum and integrals symbolically. This should be separate from the rotation matrix operator and should be in the same category object as the GC and Wigner symbols. This will allow us to implement all of the symmetry relationships that D satisfies as well. * Currently I have implemented one of the differential representations of d(J,m,m') from section 4.3.2. I think that is probably OK for integer spin, but for half integer spins we should use one of the formulas from section 4.3.1 that are a sum over k. Brian, Sean, I think that we should have a WignerD class, that will behave just like this: http://reference.wolfram.com/mathematica/ref/WignerD.html I am +1 on this with one exception. I think that it should be symbolic and not return the actual function be default. This way we can use this class in a symbolic manner when manipulating various kinds of sums and integrals. This mean that the class would have a method that returns the actual representation in terms of cos(), sin(). except that it will be called like WignerD(j, m, mp, alpha, beta, gamma), at least that's what I would propose, Yep. and it will be thoroughly tested and so on. Then Rotation.D() will return WignerD(j, m, mp, alpha, beta, gamma) and Rotation.d() will return WignerD(j, m, mp, 0, beta, 0). Yep. Let me know what you think. This will keep things simple and clean and be compatible with Mathematica. I like this idea. Brian Ondrej -- You received this message because you are subscribed to the Google Groups sympy group. To post to this group, send email to sympy@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. -- Brian E. Granger Cal Poly State University, San Luis Obispo bgran...@calpoly.edu and elliso...@gmail.com -- You received this message because you are subscribed to the Google Groups sympy group. To post to this group, send email to sympy@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.
Re: [sympy] Re: Some changes to representations in sympy.physics.quantum
Tomo, Great, keep us posted. I am around today and will be on IRC much of the day. Cheers, Brian On Fri, Jun 17, 2011 at 10:14 AM, Tomo Lazovich lazov...@fas.harvard.edu wrote: Ok. I will take a look at deltaintegrate today. I've already written a bit of code for collapsing delta functions in represent, so we'll see how easy it is to move over. On Fri, Jun 17, 2011 at 12:33 AM, Brian Granger elliso...@gmail.com wrote: I didn't know there was a specialized function for this. I agree with Aaron that we should improve deltaintegrate and fix its bugs in a separate pull request *before* continuing with the represent work. On Thu, Jun 16, 2011 at 9:58 PM, Aaron Meurer asmeu...@gmail.com wrote: On Thu, Jun 16, 2011 at 10:53 PM, Brian Granger elliso...@gmail.com wrote: Tomo, Replies inline... On Tue, Jun 14, 2011 at 12:31 PM, Tomo Lazovich lazov...@fas.harvard.edu wrote: Hi Brian, Thank you for all the detailed feedback! Some responses below: On Tue, Jun 14, 2011 at 1:18 PM, Brian Granger elliso...@gmail.com wrote: Tomo, Here are some notes on represent that will hopefull answer some of your questions: * Remember that not all Wavefunctions can be normalized. * The notion of normalization on wavefunctions in 2D/3D depends on the coordinate system, though factors like r**2, sin(theta). From that standpoint, I am not sure it makes sense to teach wavefunctions in general about normalization. I'll have to think a bit more about this normalization stuff in the different coordinate systems, but I think you're probably right that it doesn't make much sense. * Rather than using Piecewise to specify the range of a wavefunction, we should probably have a notion of the range of each spatial coordinate. This information is obviously related to coordinate transforms as angular coordinates have limited ranges always. I agree with this. It probably makes sense to think about ways to specify which variables are spatial coordinates, which are indices for the states, etc. Wavefunction should be able to handle all of this in a clean way. Yes, maybe Wavefunction can take a list of spatial (or momentum) coordinate and their ranges: (x, -oo,oo), (y, 0, L) or (r, 0, oo), (theta, 0, pi), (phi, 0, 2*pi) * I am not sure about giving States and Operators a default_label. It seems like there might be a better place for this. On the level of States and Operators themselves, the default_label isn't much more than a convenience. I think it's kind of nice to be able just say X = XOp() and have it automatically carry the default label with it. In represent, the only part of the default labeling that is used is based on what comes out of the operator specified in the basis option, which is what we'd like to be using anyway. It's true that represent should be careful about the indexing, which I hadn't considered before. More on that below. I agree that we want to be able to do things like XOp() and that a default label makes sense for that. * Let's think more carefully about represent... First, there are two core cases that represent must handle: 1. When the individual elements in the Mul have representations that are vectors and matrices. 2. When the individual elements in the Mul are differential operators and functions. I think we have a good handle on (1), and it is really two that we need to think more carefully about. Let's take a general quantum expression that is a Mul: A*B*|psiphi|*C*D*|alphabeta| Along with a basis set (say XOp for now). In the first step, we find the representation of each element: A = x1|A|x2 = A(x1,x2) B = x2|B|x3 = B(x2,x1) |psi = x3|psi = psi(x3) phi| = phi|x4 = conjugate(phi(x4)) C = x4|C|x5 = C(x4,x5) D = x5|D|x6 = D(x5,x6) |alpha = x6|alpha = alpha(x6) beta| = beta|x7 = conjugate(beta(x7)) Somethings to notice in this: * The coordinate names for each individual elements are linked. This is because what we are really doing is inserting unities: int |x1x1| etc. This careful linking of coordinate means that represent itself must be in charge of which coordinate names are used for each element. I agree that represent should be more careful about the labeling, but I still think if it keeps track of an index of some sort it can use the _get_basis_kets built into the HermitianOperator class. I don't think we should use the _get_basis_kets functionality for representing states. All of the actual representation logic for individual states and operators should be done in the _represent_Foo methods for those objects, NOT by taking inner products. Obviously, if a user does the inner products by hand, they should get the same result, but represent
Re: [sympy] Problem with evaluating rotation operator
Sean,
Here are some notes I sent to you earlier in the summer. The points
made here are quite important..
So there are some things you should know about the Wigner D matrix:
* While I implemented it, I have 0 confidence that the current
implementation is free of bugs. Because of this, one of the first
tasks should be to test this part of the code extensively, both for
numerical and symbolic arguments.
I would test the D and d matrix code thoroughly *before* moving on to
anything else. It would be great to see a pull request for that.
* The current method of computing the D matrix is not optimal. This
is because we probably want to use a different form for the integer
and half integer spin values. This is to get the canonical forms
where, for 1/2 integer spins there are things like sin(theta/2) and
cos(theta/2), but for integer spins, sin(theta) and cos(theta) appear.
This should be implemented and then tested extensively.
This will also help in testing and comparing to the tables in Varsh.
* Let's use the convention of Varshalovich for the D-matrices. He
follows the convention of most of the other main people in the field
(see Table 4.2 for a list).
* We should use his convention for Euler angles as well.
* Because of the intimate relationship between CG, Wigner 3j6j, etc
and the rotation matrices, we probably want to have a symbolic DMatrix
class that we can use when we are representing various sum and
integrals symbolically. This should be separate from the rotation
matrix operator and should be in the same category object as the GC
and Wigner symbols. This will allow us to implement all of the
symmetry relationships that D satisfies as well.
* Currently I have implemented one of the differential representations
of d(J,m,m') from section 4.3.2. I think that is probably OK for
integer spin, but for half integer spins we should use one of the
formulas from section 4.3.1 that are a sum over k.
This very important I think...
* When testing d(j,m,m') we probably want to simply go through the
specific cases from Tables 4.3, 4.4, 4.5 (j=1/2,1,3/2).
It looks like Ondrej has helped to track down the actual bug in the
current implementation, BUT that does solve the issue of the tests and
implementing a different approach for 1/2 in integer spins.
Cheers,
Brian
On Thu, Jun 16, 2011 at 8:34 PM, Ondrej Certik ondrej.cer...@gmail.com wrote:
On Thu, Jun 16, 2011 at 6:38 PM, Ondrej Certik ondrej.cer...@gmail.com
wrote:
On Thu, Jun 16, 2011 at 12:04 AM, Sean Vig sean.v@gmail.com wrote:
Hi all,
In working on some stuff with spin states, I ran into some problems with the
current implementation of the Wigner small-d matrix, Rotation.d in
sympy.physics.quantum.spin. I had written methods to change bases using the
Wigner D-function [0] and in testing decided to try
qapply(JzBra(1,1)*JzKet(1,1).rewrite('Jx'))
which should be 1, as the spin ket is rewritten in the Jx basis and then
back to the Jz basis to apply the innerproduct, but I have that it gives 0.
I traced this back to a bug in the Rotation.d function, which currently has
an open issue [1]. For the Wigner D-function and the small d-matrix, the
conventions laid out in Varshalovich Quantum Theory of Angular Momentum.
It seems the d-matrix is fine for positive values of angle argument, but
does not obey the symmetry d(j,m,mp,-beta)=(-1)**(m-mp)*d(j,m,mp,beta) and
does not agree with the tables in Varshalovich. Those terms that fail for
the j=1 case are in an XFAIL test in my branch. What is odd is that when I
I think there is a bug in the code. See my comment here:
http://code.google.com/p/sympy/issues/detail?id=2423#c3
The correct results for general beta are:
d(1, 0, 1, beta) = sin(beta)/sqrt(2)
d(1, 1, 0, beta) = -sin(beta)/sqrt(2)
However, sympy gives:
Rotation.d(1,0,1,beta)
⎽⎽⎽
╲╱ 2 ⋅(2⋅cos(β) + 2)
4
Rotation.d(1,1,0,beta)
⎽⎽⎽
-╲╱ 2 ⋅(cos(β) + 1)
───
2
Which is wrong (it looks quite ok, that it changes sign, as it should,
but something is wrong with the cos(beta) thing). The sympy code
implements the Eq. 7 in Section 4.3.2 of Varshalovich.
ran the equation used to define the d-matrix through Mathematica, I got
results that agreed with the sympy output, so the problem may be in the
equation and not a bug in the code. If anyone could take a look at that, I'd
appreciate it.
Which *exact* equation did you run through Mathematica? Eq. 7 in
section 4.3.2? What *exactly* did you get? Did you get an expression
involving cos(beta), just like sympy above? Can you paste here the
Mathematica code? I'll run it with my Mathematica, to verify, that we
didn't make a mistake.
Now we just need to systematically look at it, and nail it down. We
need to get the correct expressions:
d(1, 0, 1, beta) = sin(beta)/sqrt(2)
d(1, 1, 0, beta) = -sin(beta)/sqrt(2)
one way or the other, for general beta. Then things will start to work.
Sean,
Re: [sympy] Re: Some changes to representations in sympy.physics.quantum
Tomo, Replies inline... On Tue, Jun 14, 2011 at 12:31 PM, Tomo Lazovich lazov...@fas.harvard.edu wrote: Hi Brian, Thank you for all the detailed feedback! Some responses below: On Tue, Jun 14, 2011 at 1:18 PM, Brian Granger elliso...@gmail.com wrote: Tomo, Here are some notes on represent that will hopefull answer some of your questions: * Remember that not all Wavefunctions can be normalized. * The notion of normalization on wavefunctions in 2D/3D depends on the coordinate system, though factors like r**2, sin(theta). From that standpoint, I am not sure it makes sense to teach wavefunctions in general about normalization. I'll have to think a bit more about this normalization stuff in the different coordinate systems, but I think you're probably right that it doesn't make much sense. * Rather than using Piecewise to specify the range of a wavefunction, we should probably have a notion of the range of each spatial coordinate. This information is obviously related to coordinate transforms as angular coordinates have limited ranges always. I agree with this. It probably makes sense to think about ways to specify which variables are spatial coordinates, which are indices for the states, etc. Wavefunction should be able to handle all of this in a clean way. Yes, maybe Wavefunction can take a list of spatial (or momentum) coordinate and their ranges: (x, -oo,oo), (y, 0, L) or (r, 0, oo), (theta, 0, pi), (phi, 0, 2*pi) * I am not sure about giving States and Operators a default_label. It seems like there might be a better place for this. On the level of States and Operators themselves, the default_label isn't much more than a convenience. I think it's kind of nice to be able just say X = XOp() and have it automatically carry the default label with it. In represent, the only part of the default labeling that is used is based on what comes out of the operator specified in the basis option, which is what we'd like to be using anyway. It's true that represent should be careful about the indexing, which I hadn't considered before. More on that below. I agree that we want to be able to do things like XOp() and that a default label makes sense for that. * Let's think more carefully about represent... First, there are two core cases that represent must handle: 1. When the individual elements in the Mul have representations that are vectors and matrices. 2. When the individual elements in the Mul are differential operators and functions. I think we have a good handle on (1), and it is really two that we need to think more carefully about. Let's take a general quantum expression that is a Mul: A*B*|psiphi|*C*D*|alphabeta| Along with a basis set (say XOp for now). In the first step, we find the representation of each element: A = x1|A|x2 = A(x1,x2) B = x2|B|x3 = B(x2,x1) |psi = x3|psi = psi(x3) phi| = phi|x4 = conjugate(phi(x4)) C = x4|C|x5 = C(x4,x5) D = x5|D|x6 = D(x5,x6) |alpha = x6|alpha = alpha(x6) beta| = beta|x7 = conjugate(beta(x7)) Somethings to notice in this: * The coordinate names for each individual elements are linked. This is because what we are really doing is inserting unities: int |x1x1| etc. This careful linking of coordinate means that represent itself must be in charge of which coordinate names are used for each element. I agree that represent should be more careful about the labeling, but I still think if it keeps track of an index of some sort it can use the _get_basis_kets built into the HermitianOperator class. I don't think we should use the _get_basis_kets functionality for representing states. All of the actual representation logic for individual states and operators should be done in the _represent_Foo methods for those objects, NOT by taking inner products. Obviously, if a user does the inner products by hand, they should get the same result, but represent should not use that approach. * Bras and Kets require 1 coordinate. * Operators require 2 coordinates. * The one thing that *is* determined by the basis is the letter x. But this is determined by the Basis, not the Operators or States being represented. * represent should take the base letter for the coordinate and append numbers to them, 1, 2, 3,... to get x_1, x_2, x_3 (this will make printing nice. Is there much of a difference between having this done in the get_basis_kets function of HermitianOperator and having it done in represent itself? Yes, as I said above, we should not use get_basis_kets an inner product to implement represent logic. The reason for this is that representing some classes of states or operators can get very computationally expensive. Putting all of the logic into represent and the _represent_Foo methods will allow us to build in smart optimizations over time, such as: * Cython based code for generating
Re: [sympy] Re: Some changes to representations in sympy.physics.quantum
Tomo, I think this has been covered, but just to make sure... On Tue, Jun 14, 2011 at 1:37 PM, Tomo Lazovich lazov...@fas.harvard.edu wrote: Another question related to this approach... Let's say we're trying to represent a simpler expression, like X|x. We could actually do it two different ways: the first being a simple x_1|X|x = x*DiracDelta(x-x_1) This is correct. If we want to do the more general approach, which would work for larger expressions as well, then we would do x_1|X|x_2x_2|x = x_2*DiracDelta(x_2-x1)*DiracDelta(x-x_2) This (integrated over x_2) is also correct. We then have to integrate over x_2, which (I think) would give us x_1*DiracDelta(x-x_1). But x*DiracDelta(x-x_1) = x_1*DiracDelta(x-x_1) To see this, integrate both expressions over x or x_1. Why are these two approaches not consistent? Am I calculating the integral wrong? If you just calculate this integral with integrate(), it simply returns x_1. On Tue, Jun 14, 2011 at 1:18 PM, Brian Granger elliso...@gmail.com wrote: Tomo, Here are some notes on represent that will hopefull answer some of your questions: * Remember that not all Wavefunctions can be normalized. * The notion of normalization on wavefunctions in 2D/3D depends on the coordinate system, though factors like r**2, sin(theta). From that standpoint, I am not sure it makes sense to teach wavefunctions in general about normalization. * Rather than using Piecewise to specify the range of a wavefunction, we should probably have a notion of the range of each spatial coordinate. This information is obviously related to coordinate transforms as angular coordinates have limited ranges always. * I am not sure about giving States and Operators a default_label. It seems like there might be a better place for this. * Let's think more carefully about represent... First, there are two core cases that represent must handle: 1. When the individual elements in the Mul have representations that are vectors and matrices. 2. When the individual elements in the Mul are differential operators and functions. I think we have a good handle on (1), and it is really two that we need to think more carefully about. Let's take a general quantum expression that is a Mul: A*B*|psiphi|*C*D*|alphabeta| Along with a basis set (say XOp for now). In the first step, we find the representation of each element: A = x1|A|x2 = A(x1,x2) B = x2|B|x3 = B(x2,x1) |psi = x3|psi = psi(x3) phi| = phi|x4 = conjugate(phi(x4)) C = x4|C|x5 = C(x4,x5) D = x5|D|x6 = D(x5,x6) |alpha = x6|alpha = alpha(x6) beta| = beta|x7 = conjugate(beta(x7)) Somethings to notice in this: * The coordinate names for each individual elements are linked. This is because what we are really doing is inserting unities: int |x1x1| etc. This careful linking of coordinate means that represent itself must be in charge of which coordinate names are used for each element. * Bras and Kets require 1 coordinate. * Operators require 2 coordinates. * The one thing that *is* determined by the basis is the letter x. But this is determined by the Basis, not the Operators or States being represented. * represent should take the base letter for the coordinate and append numbers to them, 1, 2, 3,... to get x_1, x_2, x_3 (this will make printing nice. After all of these individual elements have been represented (lets say we have a list of them) there are two things we have to do: 1. Integrate over all coordinates where |xixi| was used. Usually this will be all but the first and last (all but x1 and x7 in this case). This multiple integral shoud probably be done by hand initially to look for and collapse dirac delta function. 2. Keep things in the proper order and then convert differential operators to nested derivative. How does this sound? On Sat, Jun 4, 2011 at 1:28 PM, krastanov.ste...@gmail.com krastanov.ste...@gmail.com wrote: That's what I was saying and you are probably right that it is not the intended use case. Anyhow, I would like to have an option like this down the road (for wavefunctions, not for any inner product). On 4 June 2011 21:23, Tomo Lazovich lazov...@fas.harvard.edu wrote: Ah, I think I understand now. You are saying that, rather than simply being an expression with the dummy variable, it should actually be a function that could be evaluated at any arbitrary value? I'm not sure what the intended use case was, but I think that this is something that is a virtue of how innerproduct.py is implemented, not represent. The evaluated inner product is an expression rather than a function. Perhaps the author of innerproduct can comment on that. On Sat, Jun 4, 2011 at 11:38 AM, krastanov.ste...@gmail.com krastanov.ste...@gmail.com wrote: Hi, I'll try to explain my first question. For the rest, I believe
Re: [sympy] Re: Some changes to representations in sympy.physics.quantum
I didn't know there was a specialized function for this. I agree with Aaron that we should improve deltaintegrate and fix its bugs in a separate pull request *before* continuing with the represent work. On Thu, Jun 16, 2011 at 9:58 PM, Aaron Meurer asmeu...@gmail.com wrote: On Thu, Jun 16, 2011 at 10:53 PM, Brian Granger elliso...@gmail.com wrote: Tomo, Replies inline... On Tue, Jun 14, 2011 at 12:31 PM, Tomo Lazovich lazov...@fas.harvard.edu wrote: Hi Brian, Thank you for all the detailed feedback! Some responses below: On Tue, Jun 14, 2011 at 1:18 PM, Brian Granger elliso...@gmail.com wrote: Tomo, Here are some notes on represent that will hopefull answer some of your questions: * Remember that not all Wavefunctions can be normalized. * The notion of normalization on wavefunctions in 2D/3D depends on the coordinate system, though factors like r**2, sin(theta). From that standpoint, I am not sure it makes sense to teach wavefunctions in general about normalization. I'll have to think a bit more about this normalization stuff in the different coordinate systems, but I think you're probably right that it doesn't make much sense. * Rather than using Piecewise to specify the range of a wavefunction, we should probably have a notion of the range of each spatial coordinate. This information is obviously related to coordinate transforms as angular coordinates have limited ranges always. I agree with this. It probably makes sense to think about ways to specify which variables are spatial coordinates, which are indices for the states, etc. Wavefunction should be able to handle all of this in a clean way. Yes, maybe Wavefunction can take a list of spatial (or momentum) coordinate and their ranges: (x, -oo,oo), (y, 0, L) or (r, 0, oo), (theta, 0, pi), (phi, 0, 2*pi) * I am not sure about giving States and Operators a default_label. It seems like there might be a better place for this. On the level of States and Operators themselves, the default_label isn't much more than a convenience. I think it's kind of nice to be able just say X = XOp() and have it automatically carry the default label with it. In represent, the only part of the default labeling that is used is based on what comes out of the operator specified in the basis option, which is what we'd like to be using anyway. It's true that represent should be careful about the indexing, which I hadn't considered before. More on that below. I agree that we want to be able to do things like XOp() and that a default label makes sense for that. * Let's think more carefully about represent... First, there are two core cases that represent must handle: 1. When the individual elements in the Mul have representations that are vectors and matrices. 2. When the individual elements in the Mul are differential operators and functions. I think we have a good handle on (1), and it is really two that we need to think more carefully about. Let's take a general quantum expression that is a Mul: A*B*|psiphi|*C*D*|alphabeta| Along with a basis set (say XOp for now). In the first step, we find the representation of each element: A = x1|A|x2 = A(x1,x2) B = x2|B|x3 = B(x2,x1) |psi = x3|psi = psi(x3) phi| = phi|x4 = conjugate(phi(x4)) C = x4|C|x5 = C(x4,x5) D = x5|D|x6 = D(x5,x6) |alpha = x6|alpha = alpha(x6) beta| = beta|x7 = conjugate(beta(x7)) Somethings to notice in this: * The coordinate names for each individual elements are linked. This is because what we are really doing is inserting unities: int |x1x1| etc. This careful linking of coordinate means that represent itself must be in charge of which coordinate names are used for each element. I agree that represent should be more careful about the labeling, but I still think if it keeps track of an index of some sort it can use the _get_basis_kets built into the HermitianOperator class. I don't think we should use the _get_basis_kets functionality for representing states. All of the actual representation logic for individual states and operators should be done in the _represent_Foo methods for those objects, NOT by taking inner products. Obviously, if a user does the inner products by hand, they should get the same result, but represent should not use that approach. * Bras and Kets require 1 coordinate. * Operators require 2 coordinates. * The one thing that *is* determined by the basis is the letter x. But this is determined by the Basis, not the Operators or States being represented. * represent should take the base letter for the coordinate and append numbers to them, 1, 2, 3,... to get x_1, x_2, x_3 (this will make printing nice. Is there much of a difference between having this done in the get_basis_kets function of HermitianOperator and having it done in represent itself? Yes, as I said above, we
Re: [sympy] Re: Some changes to representations in sympy.physics.quantum
Tomo, Here are some notes on represent that will hopefull answer some of your questions: * Remember that not all Wavefunctions can be normalized. * The notion of normalization on wavefunctions in 2D/3D depends on the coordinate system, though factors like r**2, sin(theta). From that standpoint, I am not sure it makes sense to teach wavefunctions in general about normalization. * Rather than using Piecewise to specify the range of a wavefunction, we should probably have a notion of the range of each spatial coordinate. This information is obviously related to coordinate transforms as angular coordinates have limited ranges always. * I am not sure about giving States and Operators a default_label. It seems like there might be a better place for this. * Let's think more carefully about represent... First, there are two core cases that represent must handle: 1. When the individual elements in the Mul have representations that are vectors and matrices. 2. When the individual elements in the Mul are differential operators and functions. I think we have a good handle on (1), and it is really two that we need to think more carefully about. Let's take a general quantum expression that is a Mul: A*B*|psiphi|*C*D*|alphabeta| Along with a basis set (say XOp for now). In the first step, we find the representation of each element: A=x1|A|x2=A(x1,x2) B=x2|B|x3=B(x2,x1) |psi = x3|psi =psi(x3) phi| = phi|x4 =conjugate(phi(x4)) C=x4|C|x5=C(x4,x5) D=x5|D|x6=D(x5,x6) |alpha = x6|alpha =alpha(x6) beta| = beta|x7=conjugate(beta(x7)) Somethings to notice in this: * The coordinate names for each individual elements are linked. This is because what we are really doing is inserting unities: int |x1x1| etc. This careful linking of coordinate means that represent itself must be in charge of which coordinate names are used for each element. * Bras and Kets require 1 coordinate. * Operators require 2 coordinates. * The one thing that *is* determined by the basis is the letter x. But this is determined by the Basis, not the Operators or States being represented. * represent should take the base letter for the coordinate and append numbers to them, 1, 2, 3,... to get x_1, x_2, x_3 (this will make printing nice. After all of these individual elements have been represented (lets say we have a list of them) there are two things we have to do: 1. Integrate over all coordinates where |xixi| was used. Usually this will be all but the first and last (all but x1 and x7 in this case). This multiple integral shoud probably be done by hand initially to look for and collapse dirac delta function. 2. Keep things in the proper order and then convert differential operators to nested derivative. How does this sound? On Sat, Jun 4, 2011 at 1:28 PM, krastanov.ste...@gmail.com krastanov.ste...@gmail.com wrote: That's what I was saying and you are probably right that it is not the intended use case. Anyhow, I would like to have an option like this down the road (for wavefunctions, not for any inner product). On 4 June 2011 21:23, Tomo Lazovich lazov...@fas.harvard.edu wrote: Ah, I think I understand now. You are saying that, rather than simply being an expression with the dummy variable, it should actually be a function that could be evaluated at any arbitrary value? I'm not sure what the intended use case was, but I think that this is something that is a virtue of how innerproduct.py is implemented, not represent. The evaluated inner product is an expression rather than a function. Perhaps the author of innerproduct can comment on that. On Sat, Jun 4, 2011 at 11:38 AM, krastanov.ste...@gmail.com krastanov.ste...@gmail.com wrote: Hi, I'll try to explain my first question. For the rest, I believe your response was clear. I would like to be able to have a ket, apply represent on it and get a wavefunction (I'll call it wave_func ). To me it seems that what you have is the expression wave_func(dummy_x) and not the function dummy_x -- wave_func(dummy_x). In other words, your dummy_x is in the namespace and a substitution must be applied. Maybe I'm using some Maple jargon here but I hope it is nonetheless clear. Again, I stress on the fact that I have not tried to use cartesian.py yet. So maybe I'm missing the point. Stefan On 4 June 2011 15:50, Tomo Lazovich lazov...@fas.harvard.edu wrote: Hi Stefan, Thanks for your comments! Some responses below: On Sat, Jun 4, 2011 at 5:42 AM, krastanov.ste...@gmail.com krastanov.ste...@gmail.com wrote: Hi, It's quite probable that I just don't understand the logic behind represent.py but I have a question here. Shouldn't the representation of |ket in the continuous basis X be a function of some variable (as opposed to an expression)? Something like dummy_x -- dummy_x|ket That makes it unnecessary to define a dummy
Re: [sympy] Re: Some changes to representations in sympy.physics.quantum
Tomo, A few other points: * For representing TensorProducts of states and operators, we will have to have additional custom logic. * When operators are represented in non-cartesian coordinate systems, the Dirac-delta function will have to carry around the scale factors (r**2 sin(theta)) for that coordinate system. * For non-cartesian coordinate systems, the integrals will also have to carry around the scale factors. Because of these things, it is important to design everything for the general 2d/3d curvilinear coordinate system case. Cheers, Brian On Tue, Jun 14, 2011 at 11:18 AM, Brian Granger elliso...@gmail.com wrote: Tomo, Here are some notes on represent that will hopefull answer some of your questions: * Remember that not all Wavefunctions can be normalized. * The notion of normalization on wavefunctions in 2D/3D depends on the coordinate system, though factors like r**2, sin(theta). From that standpoint, I am not sure it makes sense to teach wavefunctions in general about normalization. * Rather than using Piecewise to specify the range of a wavefunction, we should probably have a notion of the range of each spatial coordinate. This information is obviously related to coordinate transforms as angular coordinates have limited ranges always. * I am not sure about giving States and Operators a default_label. It seems like there might be a better place for this. * Let's think more carefully about represent... First, there are two core cases that represent must handle: 1. When the individual elements in the Mul have representations that are vectors and matrices. 2. When the individual elements in the Mul are differential operators and functions. I think we have a good handle on (1), and it is really two that we need to think more carefully about. Let's take a general quantum expression that is a Mul: A*B*|psiphi|*C*D*|alphabeta| Along with a basis set (say XOp for now). In the first step, we find the representation of each element: A = x1|A|x2 = A(x1,x2) B = x2|B|x3 = B(x2,x1) |psi = x3|psi = psi(x3) phi| = phi|x4 = conjugate(phi(x4)) C = x4|C|x5 = C(x4,x5) D = x5|D|x6 = D(x5,x6) |alpha = x6|alpha = alpha(x6) beta| = beta|x7 = conjugate(beta(x7)) Somethings to notice in this: * The coordinate names for each individual elements are linked. This is because what we are really doing is inserting unities: int |x1x1| etc. This careful linking of coordinate means that represent itself must be in charge of which coordinate names are used for each element. * Bras and Kets require 1 coordinate. * Operators require 2 coordinates. * The one thing that *is* determined by the basis is the letter x. But this is determined by the Basis, not the Operators or States being represented. * represent should take the base letter for the coordinate and append numbers to them, 1, 2, 3,... to get x_1, x_2, x_3 (this will make printing nice. After all of these individual elements have been represented (lets say we have a list of them) there are two things we have to do: 1. Integrate over all coordinates where |xixi| was used. Usually this will be all but the first and last (all but x1 and x7 in this case). This multiple integral shoud probably be done by hand initially to look for and collapse dirac delta function. 2. Keep things in the proper order and then convert differential operators to nested derivative. How does this sound? On Sat, Jun 4, 2011 at 1:28 PM, krastanov.ste...@gmail.com krastanov.ste...@gmail.com wrote: That's what I was saying and you are probably right that it is not the intended use case. Anyhow, I would like to have an option like this down the road (for wavefunctions, not for any inner product). On 4 June 2011 21:23, Tomo Lazovich lazov...@fas.harvard.edu wrote: Ah, I think I understand now. You are saying that, rather than simply being an expression with the dummy variable, it should actually be a function that could be evaluated at any arbitrary value? I'm not sure what the intended use case was, but I think that this is something that is a virtue of how innerproduct.py is implemented, not represent. The evaluated inner product is an expression rather than a function. Perhaps the author of innerproduct can comment on that. On Sat, Jun 4, 2011 at 11:38 AM, krastanov.ste...@gmail.com krastanov.ste...@gmail.com wrote: Hi, I'll try to explain my first question. For the rest, I believe your response was clear. I would like to be able to have a ket, apply represent on it and get a wavefunction (I'll call it wave_func ). To me it seems that what you have is the expression wave_func(dummy_x) and not the function dummy_x -- wave_func(dummy_x). In other words, your dummy_x is in the namespace and a substitution must be applied. Maybe I'm using some Maple jargon here but I hope it is nonetheless
Re: [sympy] Re: [IPython-User] isympy in newest ipython
OK, then the issue is having the wrong version of IPython installed. But, the test suite should be independent of IPython (even the wrong version). Cheers, Brian I don't have IPython installed and the SymPy tests run just fine. Cheers, Brian On Mon, Jun 13, 2011 at 5:12 PM, Brian Granger elliso...@gmail.com wrote: Ondrej, On Mon, Jun 13, 2011 at 1:49 PM, Ondrej Certik ond...@certik.cz wrote: On Mon, Jun 13, 2011 at 1:44 PM, Brian Granger elliso...@gmail.com wrote: But they probably want to start this at the application level right? So the config gets parsed. Ondrej, we should figure this out before sympy0.7 is released so that isympy works with the soon-to-be-released IPython 0.11. That's right, we should definitely figure this out before sympy 0.7.0. As I see it, we will try to import the old ipython, and if it fails, then some preferred way in the new ipython. I will play with this in the evening and provide some options that work, and you can then tell me, if it is going to be supported in the IPython 0.11. Do you want things like command line flags and config file parsing to work? If so (I imagine you do) I would look at subclassing the main IPython application. BUT, this part of the 0.11 is still ongoing and has not been merged into master yet, so it could be difficult to rely on it *today*. But, we do plan on releasing before SciPy in July and that part of the code should be stable soon. This may be an issue if you are trying to release in the next few days. Brian Ondrej -- You received this message because you are subscribed to the Google Groups sympy group. To post to this group, send email to sympy@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. -- Brian E. Granger Cal Poly State University, San Luis Obispo bgran...@calpoly.edu and elliso...@gmail.com -- Brian E. Granger Cal Poly State University, San Luis Obispo bgran...@calpoly.edu and elliso...@gmail.com -- You received this message because you are subscribed to the Google Groups sympy group. To post to this group, send email to sympy@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. -- Vladimir Perić -- You received this message because you are subscribed to the Google Groups sympy group. To post to this group, send email to sympy@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. -- Brian E. Granger Cal Poly State University, San Luis Obispo bgran...@calpoly.edu and elliso...@gmail.com -- You received this message because you are subscribed to the Google Groups sympy group. To post to this group, send email to sympy@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.
[sympy] Re: [IPython-User] isympy in newest ipython
But they probably want to start this at the application level right? So the config gets parsed. Ondrej, we should figure this out before sympy0.7 is released so that isympy works with the soon-to-be-released IPython 0.11. On Mon, Jun 13, 2011 at 12:19 AM, Min RK benjami...@gmail.com wrote: I believe it should be: from IPython.core.interactiveshell import InteractiveShell ip = InteractiveShell.instance() -MinRK On Jun 12, 2011, at 23:31, Ondrej Certik ond...@certik.cz wrote: Hi, when I try to import isympy in the newest ipython (installed in Qsnake from qsnake.com), I get: Qsnake: ondrej@eagle:~/repos/sympy(cg_coeff)$ bin/isympy Traceback (most recent call last): File bin/isympy, line 180, in module main() File bin/isympy, line 177, in main init_session(ipython, **args) File sympy/interactive/session.py, line 122, in init_session ip = IPython.ipapi.get() AttributeError: 'module' object has no attribute 'ipapi' What is the best way that we should fix this? I would add some conditional imports into sympy, but I wanted to ask, what the final import line will be once ipython gets released. Thanks, Ondrej ___ IPython-User mailing list ipython-u...@scipy.org http://mail.scipy.org/mailman/listinfo/ipython-user ___ IPython-User mailing list ipython-u...@scipy.org http://mail.scipy.org/mailman/listinfo/ipython-user -- Brian E. Granger Cal Poly State University, San Luis Obispo bgran...@calpoly.edu and elliso...@gmail.com -- You received this message because you are subscribed to the Google Groups sympy group. To post to this group, send email to sympy@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.
Re: [sympy] Re: [IPython-User] isympy in newest ipython
Ondrej, On Mon, Jun 13, 2011 at 1:49 PM, Ondrej Certik ond...@certik.cz wrote: On Mon, Jun 13, 2011 at 1:44 PM, Brian Granger elliso...@gmail.com wrote: But they probably want to start this at the application level right? So the config gets parsed. Ondrej, we should figure this out before sympy0.7 is released so that isympy works with the soon-to-be-released IPython 0.11. That's right, we should definitely figure this out before sympy 0.7.0. As I see it, we will try to import the old ipython, and if it fails, then some preferred way in the new ipython. I will play with this in the evening and provide some options that work, and you can then tell me, if it is going to be supported in the IPython 0.11. Do you want things like command line flags and config file parsing to work? If so (I imagine you do) I would look at subclassing the main IPython application. BUT, this part of the 0.11 is still ongoing and has not been merged into master yet, so it could be difficult to rely on it *today*. But, we do plan on releasing before SciPy in July and that part of the code should be stable soon. This may be an issue if you are trying to release in the next few days. Brian Ondrej -- You received this message because you are subscribed to the Google Groups sympy group. To post to this group, send email to sympy@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. -- Brian E. Granger Cal Poly State University, San Luis Obispo bgran...@calpoly.edu and elliso...@gmail.com -- You received this message because you are subscribed to the Google Groups sympy group. To post to this group, send email to sympy@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.
Re: [sympy] Re: [IPython-User] isympy in newest ipython
Ondrej, One other thing that probably should be changed is that currently the sympy test suite requires IPython and I think the APIs it relies on have changed in significant ways. It would be nice to decouple the test suite from IPython. Cheers, Brian On Mon, Jun 13, 2011 at 5:12 PM, Brian Granger elliso...@gmail.com wrote: Ondrej, On Mon, Jun 13, 2011 at 1:49 PM, Ondrej Certik ond...@certik.cz wrote: On Mon, Jun 13, 2011 at 1:44 PM, Brian Granger elliso...@gmail.com wrote: But they probably want to start this at the application level right? So the config gets parsed. Ondrej, we should figure this out before sympy0.7 is released so that isympy works with the soon-to-be-released IPython 0.11. That's right, we should definitely figure this out before sympy 0.7.0. As I see it, we will try to import the old ipython, and if it fails, then some preferred way in the new ipython. I will play with this in the evening and provide some options that work, and you can then tell me, if it is going to be supported in the IPython 0.11. Do you want things like command line flags and config file parsing to work? If so (I imagine you do) I would look at subclassing the main IPython application. BUT, this part of the 0.11 is still ongoing and has not been merged into master yet, so it could be difficult to rely on it *today*. But, we do plan on releasing before SciPy in July and that part of the code should be stable soon. This may be an issue if you are trying to release in the next few days. Brian Ondrej -- You received this message because you are subscribed to the Google Groups sympy group. To post to this group, send email to sympy@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. -- Brian E. Granger Cal Poly State University, San Luis Obispo bgran...@calpoly.edu and elliso...@gmail.com -- Brian E. Granger Cal Poly State University, San Luis Obispo bgran...@calpoly.edu and elliso...@gmail.com -- You received this message because you are subscribed to the Google Groups sympy group. To post to this group, send email to sympy@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.
Re: [sympy] Re: Question about functions in sympy
I am -1 on having a Wavefunction class. The reason is that a
wavefunction is just a plain old function. There is no additional
logic needed over a regular function. But I want to understand what
you are using these functions for. I can think of two types of
functions needed in quantum:
* An undefined function for use in representing an unknown or abstract
state: x|psi = psi(x). For this I would just use
Function('psi')('x'). The name of the state (psi) can just be used
for the name of the function.
* A function for a known quantum state like the particle in a box.
For this case, we should just return the special function, such as
sin(n*pi*x/L), etc.
Can you clarify how the functions you are using relate to these two cases?
Cheers,
Brian
On Sat, Jun 11, 2011 at 2:56 PM, Tomo Lazovich lazov...@fas.harvard.edu wrote:
Lambda seems to work for me except for one thing.
I have a class Wavefunction for representations of states in continuous
bases. It subclasses Lambda and provides some additional convenience
functions. One thing it would like to do internally is calculate
self.expr*conjugate(self.expr). I've found, however, that because the Lambda
uses dummy variables internally, even if I initialize the function with a
symbol set to real=True, that doesn't carry over to the internal expression
and so the conjugate isn't very well simplified. Is there a way to get
around this?
Thanks!
On Fri, Jun 10, 2011 at 9:19 PM, Aaron Meurer asmeu...@gmail.com wrote:
If you just want a placeholder to keep args, use UndefinedFunction.
If you want it to have any more advanced functionality at all, create
a subclass of Function. I admit I don't know anything at all about
what you are doing, but it's very likely that the case is the latter.
Aaron Meurer
On Fri, Jun 10, 2011 at 5:08 PM, Vinzent Steinberg
vinzent.steinb...@googlemail.com wrote:
On 10 Jun., 02:08, Brian Granger elliso...@gmail.com wrote:
Definitely use the existing Function stuff in sympy. I am not sure
you will even have to subclass to do this.
There is also UndefinedFunction (BTW, I think we should rename it to
AbstractFunction or similar) if you want a rather abstract function.
If you want to implement something like sin, you should probably use
Function.
Vinzent
--
You received this message because you are subscribed to the Google
Groups sympy group.
To post to this group, send email to sympy@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.
--
You received this message because you are subscribed to the Google Groups
sympy group.
To post to this group, send email to sympy@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.
--
Tomo Lazovich
Harvard College '11
278 Winthrop House Mail Center
Cambridge, MA 02138
--
You received this message because you are subscribed to the Google Groups
sympy group.
To post to this group, send email to sympy@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.
--
Brian E. Granger
Cal Poly State University, San Luis Obispo
bgran...@calpoly.edu and elliso...@gmail.com
--
You received this message because you are subscribed to the Google Groups
sympy group.
To post to this group, send email to sympy@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.
Re: [sympy] Re: Adding sympy.physics to documentation
On Tue, Jun 7, 2011 at 10:28 PM, Luke hazelnu...@gmail.com wrote: On Tue, Jun 7, 2011 at 1:26 PM, krastanov.ste...@gmail.com krastanov.ste...@gmail.com wrote: What would the classical module contain? Won't newtonian, galilean or just mechanics be more suitable in this case? physics.classical will contain what Gilbert is working on for his GSoC project. His project is focused is on rigid body mechanics, especially multi-body systems. It provides tools for performing convenient 3d vector kinematics, as well as algorithms for deriving equations of motion automatically. I guess classical mechanics or newtonian mechanics would more precisely describe what his project is about, and we decided that it would make sense to put this sort of thing into sympy.physics.classical For example Hamiltonian mechanics applies to boot classical and quantum physics. Also optics/thermodynamics/stat. phys./etc don't play well with such separation. Perhaps it would make more sense to put his project into sympy.physics.classicalmechanics, or even just sympy.physics.mechanics? I think that classical or mechanics make the most sense. Because classical physics also includes other areas (EM, thermo, etc), maybe mechanicsa makes the most sense. Brian Anyway, this can be changed later. If you prepare the skeleton files I would be happy to go over the code and document the parts that I use. Cool, thanks! I'll mail the list when I get this up and running on a github branch. ~Luke Stefan On 7 June 2011 20:34, Luke hazelnu...@gmail.com wrote: 1) Should any of the code in sympy.physics be bundled into it's own submodule (similar to quantum and/or classical)? You could have either a 'physics' submodule and a 'classical' subsubmodule, or a 'classical physics' and a 'quantum physics' submodule. I don't really care either way, and this should be easy to change later. The first one corresponds more to the (intended) structure of the physics-related code. I think having a physics submodule with 'classical' and 'quantum' subsubmodules make sense. I'll leave the other physics subsubmodules (units, matrices, hydrogen, etc.) where they are for now and if it makes sense to rearrange things, we can do that down the road. 2) Are there reasons this part of sympy has not been added to docs.sympy.org in the past (other than lack of time)? No, it should be there, it is just that noone yet made sure it's generated correctly when building the docs. I'll get started on this. ~Luke -- You received this message because you are subscribed to the Google Groups sympy group. To post to this group, send email to sympy@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. -- You received this message because you are subscribed to the Google Groups sympy group. To post to this group, send email to sympy@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. -- Those who would give up essential liberty to purchase a little temporary safety deserve neither liberty nor safety. -- Benjamin Franklin, Historical Review of Pennsylvania, 1759 -- You received this message because you are subscribed to the Google Groups sympy group. To post to this group, send email to sympy@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. -- Brian E. Granger Cal Poly State University, San Luis Obispo bgran...@calpoly.edu and elliso...@gmail.com -- You received this message because you are subscribed to the Google Groups sympy group. To post to this group, send email to sympy@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.
Re: [sympy] Question about functions in sympy
Tomo, On Thu, Jun 9, 2011 at 4:05 PM, Tomo Lazovich lazov...@fas.harvard.edu wrote: Hi everyone, I'm thinking of implementing a Wavefunction class in sympy.physics.quantum, and as a start I'm wondering about functions in sympy in general. Disclaimer is that this is a potentially very noobish question. Definitely use the existing Function stuff in sympy. I am not sure you will even have to subclass to do this. Cheers, Brian Is there already a way in sympy to define an arbitrary functional form? I.e. to be able to easily say something like f(x) = x**2 and then evaluate f(2) or whatever else you'd like to do. Apologies if this is obvious! Tomo -- You received this message because you are subscribed to the Google Groups sympy group. To post to this group, send email to sympy@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. -- Brian E. Granger Cal Poly State University, San Luis Obispo bgran...@calpoly.edu and elliso...@gmail.com -- You received this message because you are subscribed to the Google Groups sympy group. To post to this group, send email to sympy@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.
Re: [sympy] an old pull request
Sorry I haven't gotten to this review yet, we are in the middle of the last week of classes+finals. I will do this soon though. Cheers, Brian On Thu, Jun 2, 2011 at 3:44 AM, krastanov.ste...@gmail.com krastanov.ste...@gmail.com wrote: Hi, I'm writing about an old pull request regarding some bugs/enhancements in the printing of the quantum module: https://github.com/sympy/sympy/pull/186 A week ago I explained it in more details here: https://groups.google.com/d/topic/sympy/ZacngABe3Ws/discussion Long before that Brian had expressed a concern about two things: -Not enough tests (I have added those) -The realization of the code is not great (I have explained why the code is the way it is in the last link) So I think the first point is already addressed. For the second one I need somebody to point out the problems so I can fix them. The problem is trivial but I would like to end this pull request before addressing some more interesting problems in the module (some of the spin operators/states have basic methods that are still unimplemented) Regards Stefan -- You received this message because you are subscribed to the Google Groups sympy group. To post to this group, send email to sympy@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. -- Brian E. Granger Cal Poly State University, San Luis Obispo bgran...@calpoly.edu and elliso...@gmail.com -- You received this message because you are subscribed to the Google Groups sympy group. To post to this group, send email to sympy@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.
