coverage: 94.645% (-0.04%) from 94.687%
when pulling ccf9ce1 on sdahdah:main
into 0ff0452 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 the doc/ folder I think? I have not been able to figure that out

Is there a way to run the doctests locally? make html in the doc/ 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 format
siso = (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 inside xferfcn.TransferFunction.__mul__. I think roots need to be cancelled in xferfcn._add_siso(), but I'm not sure whether minreal() 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 the Py3.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.h
libevent-2.1.12-hf998b51_1.conda extraction failed
Found incorrect download: libevent. Aborting

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