Aaron, Thanks for the suggestion about PSF. However, to me it seems natural though to apply to Sympy rather than PSF because PyDy is completely and wholly dependent on Sympy -- it can't work without it. All development of it requires interfacing with and using Sympy's functionality, not just Python. This is in contrast to something like mpmath, which can operate standalone, but also can operate with sympy, which in that case it makes sense to keep the two project separate.
I am in favor of including PyDy (or some part of it) as a module of Sympy for two reasons. First, it helps with the testing of PyDy by ensuring changes to Sympy don't break PyDy functionality. Second, when working on things such as the trig branch, where most of the simplification cases came directly from my work within PyDy, it makes it easier to write tests for sympy that ensure the functionality of PyDy. The separation between the two projects simply made concurrent development of both harder, IMHO. An example of this would be GA package benefiting from being part of Sympy and the testing framework that is in place. It would be great for PyDy to have this same type of benefit, and I think it would really help the development of both. As Ondrej said, PyDy is pretty small, so it wouldn't be a huge addition to sympy as far as the number of lines of code or number of files. With regard to the trig branch -- I think it would be great to finish up as well. In retrospect however, I think I was a bit naive as to how difficult this would be. Many aspects of it are non-trivial. I'm not sure this is something that can be easily done as a side project but rather needs the full attention of a couple of people, which explains why it is in the state it is in. I'll give it a look, but it hasn't been touched since June 26, 2009, so there may be quite a lot that breaks once I rebase from the current master. ~Luke On Apr 5, 3:02 pm, Aaron Meurer <asmeu...@gmail.com> wrote: > I agree with Ondrej. > > Since PyDy is (still at least) separate form SymPy, another idea > regarding GSoC would be to apply to work under the umbrella of Python. > Seehttp://wiki.python.org/moin/SummerOfCode/2011. You have to fill > out an application to work under them this year. I would also look at > PSU (and whatever others). I say this because the competition for > SymPy might be high this year (depending on how many slots Google > gives us). > > But again, remember that you don't have much time, as the deadline for > student applications is Friday. And remember that if the students > apply to SymPy they need to submit at patch that gets merged in (like > everyone else). > > > > > > > > > > On Tue, Apr 5, 2011 at 2:37 PM, Ondrej Certik <ond...@certik.cz> wrote: > > Hi Luke, > > > On Tue, Apr 5, 2011 at 1:08 PM, Luke <hazelnu...@gmail.com> wrote: > >> Hello, > >> I did a Sympy GSoC project in 2009 on a package called PyDy [0]. > >> PyDy depends intimately on SymPy, but currently the two projects are > >> maintained separately. The basic functionality of PyDy is to provide > >> a set of classes which ease kinematic and dynamic analysis of > >> mechanical systems that obey the laws of Newtonian Mechanics. PyDy > >> relies on the core symbolic functionality of SymPy in a way similar to > >> the Geometric Algebra module (sympy/GA.py). By the end of my GSoC > >> summer, PyDy was very functional and I had created 12 examples of use > >> for deriving equations of motion for both trivial (pendulum) and non- > >> trivial (rolling coin, rolling torus, bicycle--almost) mechanical > >> systems. Sadly, the project has seen very little activity since my > >> GSoC project. > > >> There are two students in my lab who are interested in helping develop > >> and improve PyDy. One of the ideas we have been discussing is how the > >> core functionality of PyDy really depends on Sympy and we think it > >> would make more sense to have PyDy as a module of Sympy, probably in > >> sympy/physics or maybe in sympy/pydy (or some other place?). This > >> way, it would be more like a library that can be imported along with > >> Sympy if you want to formulate study symbolic equations of motion. A > >> few advantages of this approach are: > >> -- Code updates to sympy wouldn't break pydy functionality since the > >> core testing would be done together > >> -- PyDy would be available to anybody who installs sympy. This could > >> be really helpful for both projects because there are many physics, > >> math, and engineering students (both grad and undergrad) who need to > >> do some basic 3D vector symbolic vector analysis, and keeping pydy > >> within sympy would make this much easier than it currently is. > >> -- We could maintain a separate source tree for detailed examples of > >> use, which depend on many other tools besides Sympy, and don't make > >> sense to have distributed with sympy. > >> -- Developers of PyDy would be more connected to Sympy and vice-versa, > >> which would be a win for both groups. > > >> What do people think of this idea? A fair bit of work needs to be > >> done to make the pydy code compliant with they sympy project -- > >> doctests and docstrings need to be improved, but most of the testing > >> of PyDy's functionality is already implemented. > > > I definitely like this. Given the size of pydy, it's just a couple > > (not very large) files, so it is of the size of sympy.physics.quantum, > > or sympy.galgebra. And as long as there modules are of moderate size, > > that we can manage, and currently that is 100% the case, I would love > > to have them in sympy itself. > > > The reason for that being that it will force sympy to become more > > polished as a library, in particular things like customized printing, > > that every single module is tackling with (quantum, galgebra and > > pydy). And having them nicely polished in sympy, it shows how to use > > sympy to actually do something nontrivial, in real world, that people > > want to use. > > > Plus it will inspire more people to contribute useful modules in > > various fields. This adds real value to sympy. > > >> Back to the topic of GSoC, there are many other aspects of PyDy that > >> need work besides the possibility of integrating it into sympy. Here > >> are a few items: > >> -- Class hierarchy needs to be re-evaluated/re-designed to include > >> some notion of the "system" (all bodies, particles, applied forces/ > >> torques, generalized coordinates, degrees of freedom, etc.). > >> Currently all of this is embedded in the Point and ReferenceFrame > >> classes and is a bit hackish. > >> -- Handling of closed kinematic loops (four-bar linkage) needs to be > >> improved > >> -- Templates for outputting boilerplate animation code to enable > >> immediate visualization after symbolic derivation. > >> -- Improvement of LaTeX printing for vector expressions. > > >> We are working on a document outlining these things in more detail, we > >> have made it public here: > >>https://docs.google.com/document/d/1Egkw9VkXcIYOiXonKFGRU00gycoA7w4Oq... > > >> I would like to ensure that work on Pydy is beneficial for the Sympy > >> project. Pydy is fairly heavy on the trigonometry and in the past I > >> ran into snags in various aspects of trigsimp. Part of this was > >> probably avoidable for reasons I won't go into here, but part of it > >> was due to aspects of sympy that needed improvement. I see this as > >> place of technical overlap where work on PyDy will help improve > >> Sympy. Another place where PyDy can help SymPy is by bringing more > >> uses to Sympy -- every physics and engineering student has to take a > >> dynamics class in which aspects of PyDy could be very beneficial to > >> their studies and this in turn would expose more people to Sympy. By > >> tying something this ubiquitous to Sympy, I think the user base would > >> both grow and be diversified. > > >> The two students in my lab that are interested should be posting > >> introduction emails shortly, and they are working on familiarizing > >> themselves with the Sympy source tree and identifying an issue that > >> they can fix and submit a patch for. They will be adding their > >> proposals to the wiki and notifying the mailing list as well. > > >> Seeing as both of these students are in my lab, I would be willing to > >> mentor them for the GSoC projects, should they be accepted. We use > >> git and python extensively in our lab so some of the hurdles in the > >> development process should be lowered by the resources and experience > >> of the people in my lab. This will help both students to hit the > >> ground running a lot more quickly. > > > I agree with what you wrote. > > > I would only stress one thing --- with GSoC, we really want all > > students to become part of the sympy community. We understand that we > > can't force anyone to stay around once the summer is over, but we do > > want to encourage that as much as we can, so that the whole sympy > > community can grow with GSoC. > > > By becoming part of the sympy community, we mean occasionally helping > > with reviews, or on the mailinglist, reporting bugs, helping other > > people. The best way is of course to use sympy in your daily research. > > So I can see lots of potential here, because pydy depends on lots of > > things in sympy, trigonometry being one thing, and there is tons of > > room for improvement. And pulling this off, so that more people start > > using pydy (and contribute back), would be really great. > > > Ondrej > > > P.S. that reminds me, that we still have that unfinished "trig" branch. :) > > Yes! Let's finish that! > > I have pointed that branch to people a dozen times, but no one has > been interested in trying to fix it up, so now things aren't much > further than they were with respect to trig stuff. > > 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.
