Control Systems package

[Naman Nimmo]

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

[Javier Arantegui]

Hello,

it sounds interesting.

What do you have in mind? Something like COMA <http://www.austromath.at/daten/maxima/zusatz/coma.htm>? COMA is a control engineering package for Maxima.

I have my own script inspired in COMA to do some calculationl. It uses sympy a lot. Honestly it's quite bad, but it makes my life easier.

Javier

[Jason Moore]

Naman,

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

Jason

moorepants.info
+01 530-601-9791

--
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+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/CALkUZDm4UGQz4P4Mg0XckpE2o7%2Bo8Ob26y7%2BxEWW31mNjOgYHA%40mail.gmail.com.

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

--

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+un...@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/

[Jason Moore]

Naman,

I'd have a look at the maxima package. They likely have good and useful ideas for your design.

Jason

moorepants.info
+01 530-601-9791

--

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+un...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/3aa63a5a-10a2-49a4-9806-b4bc2cbd0d6d%40googlegroups.com.

[Aaron Meurer]

My suggestion would be to start with it in SymPy, since that will be
the easiest. You won't have to deal with setting up any of the
boilerplate that is required for a separate repository, like
packaging, setting up the testing and CI, and so on.

The only concern is if we later want to move it out, if that would
present a challenge. I think Jason has the most experience with this
with PyDy and the sympy.physics.mechanics packages. I don't remember
if there was ever any major code that was moved from SymPy to PyDy or
from PyDy to SymPy. If there was, were there any challenges in this?

Aaron Meurer

> To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/CAP7f1AjsN-iQnKdV98oHYaQVKa-_UWHvJXm6m8yuaRXtL8bd9g%40mail.gmail.com.

[Naman Nimmo]

Thanks for your interest, Javier!

I was thinking of adding a basic control systems functionality in SymPy as my project. It includes the following:

*  Representation of State space and transfer function, symbolic evaluation.

*  Controllability and Observability.

*  Inter conversion between two forms.

*  Inter connection of two systems (for both Transfer function and state space)

*  And finally, root-locus and bode plots.

Maybe I have missed something but that's just an overview...

I will try to mimic the python-control

But this would be a symbolic version of that and will heavily use sympy's existing features.

We can have a look at Maxima, maybe it can help me in this project!

Thanks. 

--

[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

To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/CAAvS0gWrLcnfKhhd48gh-bG-MOusAq_St5%2BoeekApbtcSsE42w%40mail.gmail.com.

[Jason Moore]

Aaron,

The main challenge for the SymPy-PyDy codes is that we have to separate the symbolic and the numerical/visualization codes, with the numerical codes being in the external PyDy repository and that the PyDy tests are not run in the SymPy CI. It would be nice if all the code was together or if SymPy at least ran the PyDy tests against each SymPy PR. I think we could move sympy.physics.vector and sympy.physics.mechanics out of sympy and into PyDy and it would be ok at this point, but that's with the symbolic code being pretty stable and well used for a decade.

I think the model where we nurture niche packages in SymPy and then if they get popular enough they move to their own self supported repo is the best. We can always carefully deprecate and remove the package like we did with mpmath*. The only downside I see is the maintenance burden, but I think that burden is low and it is worth the benefits. We can also remove and delete packages permanently too if there don't seem to be any users. These should happen on major version changes to SymPy though.

Including domain specific packages is good for end users. Its one of the reasons Matlab is so successful. The user installs one thing and has the core language and tools as well as all domain packages. Python struggles to this day with fractured packages and JS/Node is really struggling. If we want to be a competitor to Maple, Mathematica, etc. we should support domain specific packages.

*mpmath was a self sustaining package that we vendored, but the removal model is a good one to follow.

Jason

moorepants.info
+01 530-601-9791

To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/CAKgW%3D6J5eK4G2Y4bPcg4SJThM-pC_QG-%2BYygxKU9AyBMuTgE-w%40mail.gmail.com.

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

To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/CAP7f1AhWLiGLTUJioOU_d8ONp%3DEBdCdyU_3hejiExAsZXmKeiA%40mail.gmail.com.

[Jason Moore]

Gagandeep,

Thanks for the consideration of my comments.

Jason

moorepants.info
+01 530-601-9791

To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/CAAvS0gXdvVE4TPcBa7SuSf0aJKvfAVfTR%2BKXnBXfqPGD%3DPp_mA%40mail.gmail.com.

[Naman Nimmo]

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

Thanks all for your suggestions.

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.

[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

> To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/CALkUZDmviTKOncMYDrKjHeinffqzrUM%2BS9MirYd42zzexM09Nw%40mail.gmail.com.

[Jason Moore]

Good to know!

Jason

moorepants.info
+01 530-601-9791

To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/CAKgW%3D6JCCP7QXnsQFtdd3VMQRRz4oDUqcW55C6G53WXMqTY_Nw%40mail.gmail.com.