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-control that we keep track and do that. And definitely we would hope to be able to "project" controlsys models into python-control models 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.

Amazing, he's the one who wrote python-control's Transfer Function class. :)

I have a question related to TransferFunction representation 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.