GSoC 2025: Looking for Feedback on SymPy Control Systems Ideas

[Leonardo Mangani]

Dear SymPy community,
my name is Leonardo Mangani, and I am a Computer Engineering student.
I am interested in contributing to the sympy.physics.control module during GSoC 2025 by implementing new features, most of which are mentioned here: https://github.com/sympy/sympy/wiki/GSoC-Ideas#symbolic-control-systems-sympyphysicscontrol.

I would like to know if someone is avaible to discuss my ideas and provide guidance on how I can align them with the project's goals.
Thank you for your time.

Best regards,
Leonardo Mangani

[Leonardo Mangani]

Dear Sympy Community,
I hope you are all doing well. I am writing as a follow-up to my previous message regarding my interest in contributing to the sympy.physics.control module during GSoC 2025. I would like to share some further ideas and seek your feedback to ensure that my proposals align well with the project’s goals.

As mentioned on the project ideas page, I am interested in implementing the Z-transform for discrete time systems.
In addition, I propose abstracting the concept of a transform for dynamic systems, which would encompass both the Z-transform for discrete time and the Laplace transform for continuous time. This abstraction should provide a unified framework for handling different types of systems more effectively.

Additionally, I propose the implementation of Horner’s algorithm to enhance polynomial evaluations within the module.

Furthermore, I am considering the addition of observability and reachability decompositions. My approach would involve developing these decompositions separately, as well as integrating Kalman’s decomposition where appropriate to further enhance the analysis of system dynamics.

I would greatly appreciate any feedback, suggestions, or guidance you may have regarding these ideas.
Thank you very much for your time and consideration.

Best regards,
Leonardo Mangani

[Jason Moore]

Dear Leonardo,

We welcome improvements to the control package. I encourage you to think about what things you can do with symbolics that numerical packages, like python-control, can't already do. A strong proposal for GSoC would highlight new features that leverage the symbolics.

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 visit https://groups.google.com/d/msgid/sympy/08aff550-53d9-45b0-a9ef-4804bdbc03d9n%40googlegroups.com.

[Leonardo Mangani]

Dear Jason,

I have been brainstorming potential features and improvements that might be a good fit for Sympy, and I would appreciate your initial thoughts on whether these ideas are valid and align with the project's roadmap.

• Features that work well with symbolic calculations:
  • The Routh-Hurwitz conditions, which I am currently working on (https://github.com/sympy/sympy/pull/27717).
  • Extend the support for discrete-time representations of state-space and transfer functions.
  • Implement the Jury Stability Criterion to derive conditions for discrete-time systems(a discrete-time version of the Routh-Hurwitz criteria).
• Features that could work both numerically and symbolically (with limited symbols or assumptions):
  • Develop methods for computing the Z-transform and the inverse Z-transform. (The best approach might be to compute them via pole or root analysis).
  • Derive symbolic conditions under which a system is controllable and/or observable, based on the rank of the observability and controllability matrices.
  • Implement decompositions for stability and observability (both separate decompositions and the Kalman decomposition).
  • Introduce stability-related analyses directly into the StateSpace class, offering a more general approach.
• Additional considerations if time permits:
  • Explore and address the remaining issues discussed here https://github.com/sympy/sympy/issues/26212

 I am planning to start documenting these ideas further and prepare a detailed application if you think they are worth pursuing.

Thank you very much for your time and guidance. I look forward to your feedback.

Leonardo

Il giorno mercoledì 12 febbraio 2025 alle 23:02:00 UTC+1 moore...@gmail.com ha scritto:

Dear Leonardo,

We welcome improvements to the control package. I encourage you to think about what things you can do with symbolics that numerical packages, like python-control, can't already do. A strong proposal for GSoC would highlight new features that leverage the symbolics.

Jason

moorepants.info
+01 530-601-9791

--

[Leonardo Mangani]

I uploaded my application to the wiki: https://github.com/sympy/sympy/wiki/GSoC-2025-Current-Applications.

[Jason Moore]

HI Leonardo,

Your proposal looks good so far. Here are a few comments:

1. I would caution you on refactoring the TransfefFunction class, as these efforts are a lot of work for often little gain. You also have to keep things backwards compatible.

2. Your scope is very large for 175 hours.

3. It is debatable whether adding all this plotting functionality to SymPy is that useful. A user can create symbolic controls objects, substitute numbers, and pass to python-control for many plots. Why do we need the functionality in SymPy then? One reason could be that we can better plot functions with adaptive sampling, but you can also combine python-control with the an adaptive sampling plotter to get such results. So make sure what you add is focused on symbolic utility.

Jason

moorepants.info
+01 530-601-9791

To view this discussion visit https://groups.google.com/d/msgid/sympy/c5dbb3a8-ba24-458d-8d00-567c555da65an%40googlegroups.com.

[Leonardo Mangani]

Hi Jason,

Thanks for your time and your feedback.
I believe that refactoring the TransferFunction class is a good way to integrate discrete-time systems, as it allows for greater code flexibility. Many functions can be shared between the continuous-time and discrete-time versions. Although it's a significant effort, it leads to better code management and usability. Moreover, the design discussed in my proposal is focused in backward copatibility, every TransferFunction usage for the continuous-time version will be the same as before.
I'm more than willing to discuss this further if needed to find the best alternative.

Regarding the plotting functionality, my decision to expand plotting for discrete-time was motivated by the idea to have a uniform physics.control module, ensuring that plotting works seamlessly for both continuous-time and discrete-time systems. However, if this feature is not deemed crucial, I can consider removing or reducing it in the proposal to better align with the 175-hour scope.

Thank you again for your insights. I look forward to your thoughts.

Leonardo

[Leonardo Mangani]

I’ve updated my application on the wiki by removing the plotting extension to discrete time. Do you think it’s better this way?

Here’s the previous version for comparison: https://drive.google.com/file/d/18mq7-euijdlEnOz13_HQkKTefhNtza25/view?usp=sharing