coverage: 94.645% (-0.04%) from 94.687%
when pullingccf9ce1 on sdahdah:main
into0ff0452 on python-control:main.

I'll try to review this in the coming days. In the meantime, there is a typo in a docstring ("ct.ombine_tf" should be "ct.combine_tf") that is causing a failure in the doctest check.

I'll try to review this in the coming days. In the meantime, there is a typo in a docstring ("ct.ombine_tf" should be "ct.combine_tf") that is causing a failure in the doctest check.

Thank you! Is there a way to run the doctests locally?make html in thedoc/ folder I think? I have not been able to figure that out

Is there a way to run the doctests locally?make html in thedoc/ folder I think? I have not been able to figure that out

make doctest in the doc/ directory will run the tests.

Thanks for taking a look. Would you like me to fix these before you continue the review? I might not be able to until the new year unfortunately.

As currently written, the new systems that are being created are non-minimal. For example:

s = ct.tf('s')ct.config.defaults['xferfcn.display_format'] = 'zpk'  # simpler output formatsiso = (s+1) / ((s+2) * (s+3))mimo = ct.combine_tf([  [1/s,         1/(s+4)],   [1/(s+5), (s+6)/(s**2 + 2*s + 2)]])print(siso * mimo)<TransferFunction>: sys[219]Inputs (2): ['u[0]', 'u[1]']Outputs (2): ['y[0]', 'y[1]']Input 1 to output 1:      (s + 1) (s + 5)---------------------------(s) (s + 2) (s + 3) (s + 5)Input 1 to output 2:        (s) (s + 1)---------------------------(s) (s + 2) (s + 3) (s + 5)Input 2 to output 1:        (s + 1) (s + (1-1j)) (s + (1+1j))-------------------------------------------------(s + (1-1j)) (s + (1+1j)) (s + 2) (s + 3) (s + 4)Input 2 to output 2:             (s + 1) (s + 4) (s + 6)-------------------------------------------------(s + (1-1j)) (s + (1+1j)) (s + 2) (s + 3) (s + 4)

Note the various pole/zero cancellations that appear. It seems to me that these are spurious and shouldn't show up (eg, (s+4) in the [2, 2] transfer function).

This same type of situation occurs in state space and is consistent with the results that occur if you convert the SISO system to a matrix system by hand. I'm not sure (yet) what is gong on, but this seems like something we should fix, either for this specific case or for the more general case of multiplying MIMO systems.

I need to think a bit more about what is causing this, but wanted to flag it here in case someone else has some insights. It seems to me that perfect pole/zero cancellations (and the equivalent in state space) should get sorted out ahead of time, either by not creating them or by removing them before we send things back to the user.

I took a quick look but I'm not sure. It's definitely happening insidexferfcn.TransferFunction.__mul__. I think roots need to be cancelled inxferfcn._add_siso(), but I'm not sure whetherminreal() should just be used?

Happy new year@murrayrm . I fixed some of your initial comments (and also tried to look for other instances of nonstandard docstrings and indentation along the way). I'm not 100% sure what's going on with the spurious poles and zeros, buy maybe another issue should be raised to track that?

Not sure why thePy3.12; conda Slycot; conda Pandas; conda CVXOPT ; QtAgg check is failing during setup:

error    libmamba Error when extracting package: Could not stat include/event2/keyvalq_struct.hlibevent-2.1.12-hf998b51_1.conda extraction failedFound incorrect download: libevent. Aborting

I don't think it's related to the PR