I know that SymPy is a pure python module, so adding dependencies to SciPy's optimize module is probably not gonna fly.
What is the general rule of thumb about how much numerical type of code can be included with SymPy? The ode solvers are almost strictly numerical except for some particular nice problems. Jason On Sunday, March 25, 2012 3:49:45 PM UTC-7, Matthew wrote: > > I quite like the idea of writing an ODE in SymPy and numerically computing > it elsewhere. I could see this going in two ways: > > 1) Sending simple systems to scipy's odeint - it seems ideal not to > reinvent odeint if possible > 2) Hook into the code generation module. It would be very cool to generate > C/Fortran code for this. > > On Sun, Mar 25, 2012 at 3:43 PM, Angadh Nanjangud <angad...@gmail.com>wrote: > >> Also, another idea is to write ode solvers in sympy so that we can >> numerically simulate our systems within sympy without dependencies; >> currently we use SciPy to d our numerical stuff and plotting. >> >> Angadh >> >> On Mar 25, 3:25 pm, Angadh Nanjangud <angad...@gmail.com> wrote: >> > Hi Everyone >> > >> > I'm Angadh, a third year Ph.D. student in mechanical and aerospace >> > engineering at UC-Davis and a prospective applicant for the GSoC 2012. >> > and the following are some of the ideas/things that I would like to >> > work on over the course of the summer if given the opportunity. >> > Over the winter quarter, I took a mechanics class and one of it's foci >> > was the usage of the sympy.physics.mechanics module to derive >> > equations of motion for mechanical systems. Over the course of my >> > experience with it, I felt that there were several things that could >> > be worked on to make the dynamics package more robust- >> > >> > 1. One of the things that students encountered in the class was that >> > as our systems got more complex i.e. the number of bodies or degrees >> > of freedom increased, the longer it took to generate the equations. So >> > one of the things I would like to look at would be to optimize the >> > code; to enable it to handle larger expressions. This would involve >> > looking into the .subs() and .diff() to see how they could be improved >> > upon. >> > >> > 2. Currently equations are generated using just one of several methods >> > in mechanics, Kane's formalism. I would like to look into adding >> > atleast another technique- either the Newton-Euler approach or >> > Lagrange's equations. >> > >> > 3. Another thing that I would like to do would be to improve the cross- >> > platform ability of the software i.e. to get the equations of motion >> > generated to be analyzed across various (open source) platforms such >> > as Sage. This may involve automatically updating Sage's version of >> > sympy or even writing a whole new interface for it. >> > >> > 4. A comprehensive documentation effort to make this module more >> > accessible for anyone who intends to use it. >> > >> > I would be extremely grateful if you could let me know your thoughts >> > on these ideas. >> > >> > Thanks >> > Angadh >> >> -- >> 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+unsubscribe@googlegroups.com<sympy%2bunsubscr...@googlegroups.com> >> . >> For more options, visit this group at >> http://groups.google.com/group/sympy?hl=en<http://groups.google.com/group/sympy?hl=en> >> . >> >> > -- 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/-/M0LUMbIpq5gJ. 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.
