This isn't against the rules of GSoC. However, I would caution against doing such a thing. Unless there are other people other than the GSoC student who are willing to help develop and maintain the package after the end of GSoC, the package has a very high risk of falling on the wayside.
An advantage of something being in SymPy itself is that it automatically gets full development support from the rest of the package, for instance, the tests for it are always run on Travis, it is included in any package-wide refactorings, and so on. I would say at the very least if there were to be a GSoC project that creates a new package, then that package should go on under sympy org on GitHub (github.com/sympy/new-package), so that the whole SymPy development team has access to it. I can't speak to the control idea specifically because I'm not too familiar with it. I would only say that it belongs in SymPy only if it is symbolic in nature. I would also ask if it doesn't belong in SymPy should it go in another pre-existing package, such as PyDy? I agree that I would prefer to see GSoC projects that improve some of the things that are already there. We already list "high priority" ideas on the ideas page https://github.com/sympy/sympy/wiki/gsoc-2020-ideas#high-priority. Unfortunately, some of the projects that would have the most impact would also be the most difficult. For instance, certain improvements to the polys could have enormous impacts, but these require much deeper mathematics than most other projects, as well as familiarity with a large preexisting chunk of the codebase. I think it is possible to make a project out of fixing issues. I've seen similar projects from other organizations. The important thing is that for such a project, it needs to be clearly stated what the goal of the project is, so that it can be very clear if it should pass or fail the evaluations. If any students are interested in this I think we can work out what such a project should look like. Aaron Meurer On Mon, Feb 3, 2020 at 10:09 AM Oscar Benjamin <[email protected]> wrote: > > I don't know if this fits with GSOC rules but I wonder if a better > model might be for a GSOC project to do something like: > > 1. Create a new symcontrol project to go on PyPI. > 2. Make improvements to the sympy codebase as needed in order to > implement the control theory calculations. > 3. Add an examples notebook to sympy that shows simple control theory > calculations and links out to the third party package for a more > comprehensive approach. > 4. Make the third party package tested on Travis. > > (Perhaps we should test other downstream packages on Travis as well). > > Otherwise there are a number of growing problems: > > 1. There are already 750k lines of code in sympy and much of it needs > improvement. Sympy desperately needs improvements in quality much more > than quantity. > 2. New features and API are added all the time with very little > practical rationale. > 3. Often features and the code that implements them are duplicated > because there is so much code that no one knows what already exists in > the codebase. > 4. Major new features like new packages are implemented by relative > novices leaving more experienced contributors to pick through the > pieces later. > 5. Many sympy packages are already broken, unused and unmaintained. > > I am personally much more interested in GSOC proposals that improve > existing features. Modest improvements to e.g. concrete or dsolve for > systems would be more useful to users than new domain specific > packages. > > On Mon, 3 Feb 2020 at 16:37, Jason Moore <[email protected]> wrote: > > > > Historically we've been very supportive of adding well designed domain > > specific packages. SymPy, in fact, was built originally with at least a > > partial desire for solving symbolic physics. > > > > There are of course advantages and disadvantages in doing this. > > > > My personal opinion is that we limit GSoC projects to projects that improve > > existing SymPy packages, instead of adding new packages (core or not). I'd > > love to see a GSoC proposal that just listed 50 issues in the tracker that > > would be fixed. But these new package ideas do get people excited to work > > on the project which has value in itself. Its also easier for newcomers to > > wrap their head around. > > > > Jason > > moorepants.info > > +01 530-601-9791 > > > > > > On Mon, Feb 3, 2020 at 6:16 AM Oscar Benjamin <[email protected]> > > wrote: > >> > >> In general I question whether things like this need to be part of the > >> main sympy project rather than as another project on pypi that can be > >> installed separately. If we are going to include domain-specific > >> modules that are really just built on top of sympy then I think that > >> it is important that they are in some way contributing to the rest of > >> sympy. > >> > >> For example the work that goes into creating this package could also > >> involve making improvements to things like dsolve and lambdify for > >> solving ODEs and analytically and numerically. The PR right now has > >> its own implementation for those things which I don't think is right. > >> If we need improvements to lambdify and dsolve so that they are more > >> useful for control theory then we should make those improvements which > >> will be of more general use than the control theory package itself. > >> > >> Oscar > >> > >> > >> On Mon, 3 Feb 2020 at 13:58, Naman Nimmo <[email protected]> wrote: > >> > > >> > Hi Everyone, > >> > I'm Naman Gera, from the Electronics and Communication Engineering > >> > department at the Indian Institute of Information Technology, Guwahati. > >> > > >> > I started contributing to Sympy in December 2019 and ever since then, > >> > I've learned so many things. I have immense respect for this brilliantly > >> > talented open source community. They are some of the best coders I have > >> > seen, developing open-source (even on weekends!) because they believe in > >> > it. I have raised several PRs so as to solve some issues, and after each > >> > new PR, I learned something new and also understood that particular part > >> > of code. > >> > > >> > This summer, I would like to work on adding a control package to > >> > sympy.physics. > >> > > >> > > Initially, I would try to complete the work started in #17866 > >> > I'll get the already implemented methods polished for merging. > >> > > >> > > After setting up the base classes (which are `StateSpaceModel` and > >> > > `TransferFunctionModel`), I'll add some other methods like > >> > > `observability_matrix`, `observability_subspace`, `is_observable`, > >> > > `series`, `parallel` (interconnection) and many more which can be > >> > > useful for any Engineer attempting to solve a `control` problem. > >> > > >> > > The main aim would be to make the whole model symbolic. The package > >> > > will use some of sympy's core classes like `Basic` so as to avoid > >> > > rewriting code. > >> > > >> > > In the later part of the program, I'll also introduce some graphical > >> > > analyses such as the Bode diagram, the Nyquist diagrams etc.. > >> > > >> > In the meantime, I'll take some inspiration from other CAS as much as > >> > possible. > >> > > >> > I'm also ready to implement some other ideas which the community or my > >> > potential mentor will suggest. > >> > > >> > Regards, > >> > Naman > >> > > >> > > >> > > >> > -- > >> > You received this message because you are subscribed to the Google > >> > Groups "sympy" group. > >> > To unsubscribe from this group and stop receiving emails from it, send > >> > an email to [email protected]. > >> > To view this discussion on the web visit > >> > https://groups.google.com/d/msgid/sympy/CALkUZDniQkQkpnhDMivsRBwPSyFkCLgp4EYqZpuqhE%2BLAHwrew%40mail.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 [email protected]. > >> To view this discussion on the web visit > >> https://groups.google.com/d/msgid/sympy/CAHVvXxRnbKS%3DNpwmKA7JRtDO%3Du7d-kV50pzU5VXH34roA8m7Ww%40mail.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 [email protected]. > > To view this discussion on the web visit > > https://groups.google.com/d/msgid/sympy/CAP7f1Ah%2BdPnhAZm8U-%2B5v8j8PjFVna9Z6vT6PAbmaFVpHwG6oA%40mail.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 [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/sympy/CAHVvXxRqH%3Djyw2STYccinU_O6OhXm8wTqsDFUvUgWi_xNqYkeg%40mail.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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/CAKgW%3D6KwfciRWg_M8jjSdgh0dCj7%2BKXA4u%3DeVHFrHPh7aChBbw%40mail.gmail.com.
