Repository navigation
SymPy Control Package #412
Description
Activity
Excellent! It would be great to "link" the two projects, in the sense that if there are good ideas from the SymPy project that we can pull into
python-controlthat we keep track and do that. And definitely we would hope to be able to "project"controlsysmodels intopython-controlmodels by specifying parameter values, etc, at the appropriate point in time.Also, perhaps we keep this issue open as a way to share ideas about how the project is evolving and features we should be keeping track of.
@namannimmo10 See this issue. This will be a good way for you to connect with this project and share some ideas and questions.
Reacted by Naman GeraAmazing, he's the one who wrote python-control's Transfer Function class. :)
I have a question related to
TransferFunctionrepresentation in python control.I understand that when the denominator polynomial becomes zero, the value of the transfer function becomes unbounded, and hence it should raise a ValueError.
>>> from control import TransferFunction; s = TransferFunction.s >>> G = TransferFunction([2, 1, 0], [0]); G Traceback (most recent call last): File "<stdin>", line 1, in <module> File "/home/dell/python-control/control/xferfcn.py", line 183, in __init__ % (j + 1, i + 1)) ValueError: Input 1, output 1 has a zero denominator.
But when the numerator is zero, regardless of what the denominator is, the transfer function should vanish.. & here it sets the denominator to be equal to 1.
>>> G = 0/(s**2 - s + 1); G 0 - 1 >>> type(G) <class 'control.xferfcn.TransferFunction'>
Why is it designed this way?
There are probably a couple of things going on (its been a while since that class was created):
- If the numerator of a transfer function is zero, then the transfer function still needs to exist. But for every input, the output should be zero.
- There are many equivalent transfer functions that can achieve this (for example, the original transfer function that you used or the transfer function given by 0/1).
- There was probably a desire to use a "minimal" representation (fewest number of states), so this might have been the reason for setting the denominator to a constant (1 being the natural constant to use).
There is some discussion about whether to automatically return minimal realizations in issue #244.
If I were doing this again, I would probably leave the denominator along and just set the numerator to 0.
Thanks!
If I were doing this again, I would probably leave the denominator along and just set the numerator to 0.
OK, I'll do it this way.
Interested folks can also check out sympy/sympy#19352 to keep track of the progress of the package and the relevant PRs.
I think you should add this issue to the OP too, Jason.
Hi @murrayrm!
Here's the link to my second PR on MIMO transfer functions: sympy/sympy#19761
You can share some ideas or suggestions when you have time! Thanks.- locked and limited conversation to collaborators
on Mar 13, 2021
Howdy,
We have a GSoC student at SymPy this summer who is developing a symbolic control package that will be included with SymPy in future releases. I'm co-mentoring the student. I just wanted to let the folks here know in case they want to follow along or offer any help or insight as design decisions are being made.
The student, Naman namannimmo10, has a blog which will be updated over the summer:
https://namannimmo10.github.io/emerald/
And the first pull request is here:
sympy/sympy#19390
which introduces a symbolic transfer function class.
I suspect we will have some functionality to convert the SymPy objects to equivalent numerical code in Python which will connect it to this package.
FYI
Jason