Yeah, that is a good idea -- thanks! Regardless of whether these two applicants end up being accepted, I would like to get back to working on PyDy at a steady, sustainable level. If sympy devs/users think that it makes sense to have PyDy as a SymPy module, then that is probably the first thing I would start working on.
So.... are 3D symbolic vector operations and the framework for managing orientations and positions, something that users of SymPy find useful? If so, I think this would justify it's inclusion as a module, and I would like to help make it happen. Thoughts? Thanks, ~Luke On Apr 5, 4:29 pm, "Aaron S. Meurer" <asmeu...@gmail.com> wrote: > I meant you should apply under the umbrella of PSF for GSoC in addition to > SymPy (like you probably did back when you did GSoC, submitting identical > applications). This will increase your chances of being accepted, since the > competition for SymPy could be high. It was no statement on whether or not > PyDy should be included in SymPy as a module. > > Aaron Meurer > > On Apr 5, 2011, at 4:52 PM, Luke wrote: > > > > > > > > > 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,... > > read more » -- 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.
