# [SciPy-user] signal.lti __mul__ and feedback

A. M. Archibald peridot.faceted at gmail.com
Sat Oct 21 14:34:36 CDT 2006

```On 21/10/06, Ryan Krauss <ryanlists at gmail.com> wrote:
> As I continue to try to make scipy.signal a replacment for the Matlab
> controls toolbox, I need to be able to multiply signal.lti instances
> by other instances and by constants (to model a controller transfer
> function times a plant transfer function) and I need to create a
> feedback command (i.e. closed-loop tf= Gc*Gp/(1+Gc*Gp) if Gc is the
> controller transfer function and Gp is the plant transfer function -
> assuming unity feedback).  I wanted to make sure these things haven't
> already been done and ask for any input before I get started.  I was
> basically planning to define __mul__ and __rmul__ for multiplication
> by integers, floats, or other lti instances.  When multpliying by
> other instances, I was going to just multiply the numerators and
> denominators seperately and let poly1d handle that.  The only problem
> with that is what to do when there should be a cancelation (i.e.
> (s+1)/(s+2)*(s+3)/(s+1)= [(s+3)*(s+1)]/[(s+2)*(s+1)]).  Once an
> __add__ method is defined as well, feedback is easy (I guess I would
> need a __div__ and probably an __rdiv_ as well).

One could deal with common factors by implementing a polynomial GCD
(using Euclid's method), but unfortunately in the presence of roundoff
error it becomes rather a sticky subject. When you do polynomial long
division and get a remainder, when do you consider that remainder
zero? What effect does this rounding have?

Of course, if your coefficients are all integers, this problem does
not arise, but I doubt that integer-only arrangements are of much use.
Can you simply tolerate common factors?

A. M. Archibald
```