Re: [sympy] Control Systems package

[Jason Moore]

Good to know!

Jason
moorepants.info
+01 530-601-9791


On Wed, May 6, 2020 at 1:20 PM Aaron Meurer  wrote:

> Regarding galgebra, at first it did languish quite a bit, but now it
> has been picked up by several people and is doing well
> https://github.com/pygae/galgebra. So I think the main issue is that
> for a package to do well on its own, it needs to have a strong
> community, which is independent of the SymPy community.
>
> Aaron Meurer
>
> On Wed, May 6, 2020 at 1:20 PM Naman Nimmo  wrote:
> >
> > Sounds good, I will add it to sympy.physics.
> >
> > Thanks all for your suggestions.
> >
> >
> >
> > On Thu, May 7, 2020, 00:48 Jason Moore  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 
> 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
> 

Re: [sympy] Control Systems package

[Aaron Meurer]

Regarding galgebra, at first it did languish quite a bit, but now it
has been picked up by several people and is doing well
https://github.com/pygae/galgebra. So I think the main issue is that
for a package to do well on its own, it needs to have a strong
community, which is independent of the SymPy community.

Aaron Meurer

On Wed, May 6, 2020 at 1:20 PM Naman Nimmo  wrote:
>
> Sounds good, I will add it to sympy.physics.
>
> Thanks all for your suggestions.
>
>
>
> On Thu, May 7, 2020, 00:48 Jason Moore  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) 
>>  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  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) 
  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 

Re: [sympy] Control Systems package

[Naman Nimmo]

Sounds good, I will add it to sympy.physics.

Thanks all for your suggestions.



On Thu, May 7, 2020, 00:48 Jason Moore  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  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 
 wrote:

> Hi everyone.
>
> Since the accepted GSoC projects are out now, and my 

Re: [sympy] Control Systems package

[Jason Moore]

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  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 
>>> 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 

Re: [sympy] Control Systems package

[Gagandeep Singh (B17CS021)]

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  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  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 

Re: [sympy] Control Systems package

[Jason Moore]

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  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
>> 
>> .
>>
>
>
> --
> With regards,
> Gagandeep Singh
> Github - https://github.com/czgdp1807/
> Linkedin - https://www.linkedin.com/in/czgdp1807/
> 
>
> --
> 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
> 

Re: [sympy] Control Systems package

[Jason Moore]

Naman,

I think we should add it to SymPy in the physics package.

Jason
moorepants.info
+01 530-601-9791


On Wed, May 6, 2020 at 8:43 AM Naman Nimmo  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
> 
> .
>

-- 
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/CAP7f1AgDO22kC%3D1KiQNxA8xzcWFQVOc%3DWmgJ1ROEg4DhHMaT0A%40mail.gmail.com.

Re: [sympy] Control Systems package

[Gagandeep Singh (B17CS021)]

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  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
> 
> .
>


-- 
With regards,
Gagandeep Singh
Github - https://github.com/czgdp1807/
Linkedin - https://www.linkedin.com/in/czgdp1807/


-- 
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.