Sounds good, I will add it to sympy.physics. Thanks all for your suggestions.
On Thu, May 7, 2020, 00:48 Jason Moore <moorepa...@gmail.com> wrote: > Gagandeep, > > Thanks for the consideration of my comments. > > Jason > moorepants.info > +01 530-601-9791 > > > On Wed, May 6, 2020 at 12:13 PM Gagandeep Singh (B17CS021) < > singh...@iitj.ac.in> wrote: > >> Hi Jason, >> >> Thanks for presenting points on why sub-packages should be kept in the >> main sympy repo. What I suggested was just an immature approach. Obviously, >> there will be trade-offs in too much granulation of the codebase. I didn't >> mean that what I suggested must be done. >> >> > It allows the code to be tested along with SymPy and be tied into the >> maintenance effort of SymPy. >> >> For example, the above is one of the trade-offs in carving out >> sub-packages. Testing effort increases for each sub package. In fact, >> sometimes bugs in independent sub-modules are routed to some of the core >> modules of SymPy which leads to overall betterment of the code. Granulation >> may make such things difficult to handle. >> >> > You can argue that maybe they should languish and die, but I don't >> think that is what we want. >> >> Ah! I think my points were mis-interpreted. I don't want any module to >> die. >> >> > There is the maintenance burden downside, but I think the positives far >> outweigh that negative >> >> That's quite a valid point that maintenance burden increases along with >> the increase in the size of the code base. However, since from previous >> experience, it has been observed that too much granulation isn't a good >> idea then sure we can go with the current practices. >> >> May be, we can proceed as Aaron suggested, that is first control systems >> can go into the main sympy repo. If in future it becomes sufficiently large >> and has quite a good number of contributors, then we can think of carving >> out, though at that time the situation will be very different and >> trade-offs may change. >> >> On Thu, May 7, 2020 at 12:24 AM Jason Moore <moorepa...@gmail.com> wrote: >> >>> Gangandeep, >>> >>> I disagree with your thoughts on this. We've dealt with this over a >>> decade ago with the symbolic pydy package (which started as a separate >>> package). After careful consideration we decided to add this to SymPy and >>> it was the right decision. It allows the code to be tested along with SymPy >>> and be tied into the maintenance effort of SymPy. It also ensures that the >>> package can live on and will likely be used by end users. For packages that >>> have very small development teams I firmly believe it is best to include in >>> the larger SymPy development effort, otherwise the packages will languish >>> and die. You can argue that maybe they should languish and die, but I don't >>> think that is what we want. We want a strong broad community that >>> contributes back to SymPy and having packages like these in SymPy helps >>> that effort. There is the maintenance burden downside, but I think the >>> positives far outweigh that negative. Another example is galgebra; I think >>> that galgebra module should not have been removed, because now it suffers >>> from lack of maintenance, developers, and users even though it is a very >>> nice and useful package. If you remove all SymPy subpackages that are the >>> leaves of the tree, there will not only be a lot of pruning of code but a >>> lot of pruning of participating developers. The community is our #1 asset >>> to being a popular package, not the code. One reason that Python itself is >>> successful is that it is "batteries included". I think we should follow >>> that same ethos with SymPy, i.e. "symbolic batteries included". >>> >>> Jason >>> moorepants.info >>> +01 530-601-9791 >>> >>> >>> On Wed, May 6, 2020 at 10:39 AM Gagandeep Singh (B17CS021) < >>> singh...@iitj.ac.in> wrote: >>> >>>> Hi, >>>> >>>> IMHO, the control systems should go as a separate repository under >>>> sympy with the main sympy repository as a dependency. >>>> >>>> In fact that should have happened with sympy.stats as well, as no other >>>> module uses features of stats and the case is other way around but that is >>>> a thing for another day. Well, I just thought of a way which could have >>>> been used to organize modules. If we make a directed graph with modules as >>>> nodes and an edge, m->n, would reflect that module n depends on module m. >>>> Then only those modules should be kept under sympy/sympy which have both >>>> in-degree and out-degree greater than 0. Those which have out-degree of 0 >>>> can be carved out as separate packages under sympy organization. However, >>>> as of now, doing this would create unnecessary pain for end users. >>>> >>>> So, control systems, AFAICT will not be used by any other module under >>>> main sympy repo, so can be kept as a separate package. >>>> >>>> On Wed, May 6, 2020 at 9:13 PM Naman Nimmo <namanger...@gmail.com> >>>> wrote: >>>> >>>>> Hi everyone. >>>>> >>>>> Since the accepted GSoC projects are out now, and my project - >>>>> "Control Theory - Implement a control systems package" was in that list, I >>>>> would like to first know whether it will be a part of the main sympy >>>>> project or some other project to go on PyPI? >>>>> >>>>> I personally feel It *should* belong to SymPy because it *is* >>>>> symbolic in nature. >>>>> I agree with what Aaron mentioned in the last thread: >>>>> >>>>> > 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 >>>>> >>>>> What are your opinions? We can do what the whole community decides >>>>> after considering all the advantages and the disadvantages of both >>>>> options. >>>>> >>>>> 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 sympy+unsubscr...@googlegroups.com. >>>>> To view this discussion on the web visit >>>>> https://groups.google.com/d/msgid/sympy/CALkUZDm4UGQz4P4Mg0XckpE2o7%2Bo8Ob26y7%2BxEWW31mNjOgYHA%40mail.gmail.com >>>>> <https://groups.google.com/d/msgid/sympy/CALkUZDm4UGQz4P4Mg0XckpE2o7%2Bo8Ob26y7%2BxEWW31mNjOgYHA%40mail.gmail.com?utm_medium=email&utm_source=footer> >>>>> . >>>>> >>>> >>>> >>>> -- >>>> With regards, >>>> Gagandeep Singh >>>> Github - https://github.com/czgdp1807/ >>>> Linkedin - https://www.linkedin.com/in/czgdp1807/ >>>> <https://www.linkedin.com/in/gdp1/> >>>> >>>> -- >>>> 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 view this discussion on the web visit >>>> https://groups.google.com/d/msgid/sympy/CAAvS0gWrLcnfKhhd48gh-bG-MOusAq_St5%2BoeekApbtcSsE42w%40mail.gmail.com >>>> <https://groups.google.com/d/msgid/sympy/CAAvS0gWrLcnfKhhd48gh-bG-MOusAq_St5%2BoeekApbtcSsE42w%40mail.gmail.com?utm_medium=email&utm_source=footer> >>>> . >>>> >>> -- >>> 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 view this discussion on the web visit >>> https://groups.google.com/d/msgid/sympy/CAP7f1AhWLiGLTUJioOU_d8ONp%3DEBdCdyU_3hejiExAsZXmKeiA%40mail.gmail.com >>> <https://groups.google.com/d/msgid/sympy/CAP7f1AhWLiGLTUJioOU_d8ONp%3DEBdCdyU_3hejiExAsZXmKeiA%40mail.gmail.com?utm_medium=email&utm_source=footer> >>> . >>> >> >> >> -- >> With regards, >> Gagandeep Singh >> Github - https://github.com/czgdp1807/ >> Linkedin - https://www.linkedin.com/in/czgdp1807/ >> <https://www.linkedin.com/in/gdp1/> >> >> -- >> 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 view this discussion on the web visit >> https://groups.google.com/d/msgid/sympy/CAAvS0gXdvVE4TPcBa7SuSf0aJKvfAVfTR%2BKXnBXfqPGD%3DPp_mA%40mail.gmail.com >> <https://groups.google.com/d/msgid/sympy/CAAvS0gXdvVE4TPcBa7SuSf0aJKvfAVfTR%2BKXnBXfqPGD%3DPp_mA%40mail.gmail.com?utm_medium=email&utm_source=footer> >> . >> > -- > 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 view this discussion on the web visit > https://groups.google.com/d/msgid/sympy/CAP7f1AhA-k%2B_TYW%2BkjhPz_nFf%2Bg6jMJmHa-LfP2qXV6nOJzMZw%40mail.gmail.com > <https://groups.google.com/d/msgid/sympy/CAP7f1AhA-k%2B_TYW%2BkjhPz_nFf%2Bg6jMJmHa-LfP2qXV6nOJzMZw%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/sympy/CALkUZDmviTKOncMYDrKjHeinffqzrUM%2BS9MirYd42zzexM09Nw%40mail.gmail.com.
