How to check if two transfer functions are the same?

I want to verify that two transfer functions are equal.

For example:

Kc = 0.4262; Ti=1.35;
C1 = pidstd(Kc,Ti);
tf(C1)
s = tf('s');
Gc1 = Kc*(1+1/(Ti*s))
assert(tf(C1) == Gc1)

Raises:

Undefined operator '==' for input arguments of type 'tf'.

Also note:

Gc1
tf(C1)
Gc1 - tf(C1)

Gc1 =

0.5754 s + 0.4262

-----------------

1.35 s

Continuous-time transfer function.

ans =

0.4262 s + 0.3157

-----------------

s

Continuous-time transfer function.

ans =

0

Static gain.

Answer 1

[Walter Roberson]

isequal(tfdata(tf(C1) - Gc1), {[0]})

This will probably fail if there are delays in the tf.

[Bill Tubbs]

Is there a reason why comparing 'Static gain' with {[0]} produces equality?

[Bill Tubbs]

Incidentally, this also seems to work:

isequal(tfdata(tf(C1) - Gc1), {0})

[Walter Roberson]

Ah of course [0] is the same as 0

When two tf are subtracted, tf class brings them to least common denominator, subtracts the numerators, and then reduces the fraction of difference divided by LCM. In the case where the two are the same then the numerator becomes 0 and the denominator is canonically set to 1. Then tfdata extracts the numerator getting 0.

[Bill Tubbs]

Understood, but why does the RHS have to be a cell? Or, why doesn't this work:

isequal(tfdata(tf(C1) - Gc1), 0)

[Walter Roberson]

tf are deliberately designed to commonly be used in arrays, Number of Inputs by Number of Outputs of them. So tfdata is designed to return the numerators of each of the tf array elements in distinguishable form, with the elements commonly not being the same length as each other. Rather than build a multidimensional array of coefficients with the first or last dimension being padded out to the longest numerator, and each element padded with leading zeros to match the longest numerator, the tfdata function simply creates a cell array of the numerators, like arrayfun of tfdata with 'uniform, 0. In the case of a scalar tf, that gives you a scalar cell array. tfdata does not then special case that scalar cell to extract the contents.

Answer 2

[Bill Tubbs]

There is an answer on Stackoverflow:

However, it does not work directly in my case:

isequal(tf(C1), Gc1)

ans =

logical

0

Need to factor the numerator and denominator so they are the same and then it works:

factor = Gc1.denominator{1}(1)
Gc1_factored = tf(Gc1.num{1}/factor,Gc1.den{1}/factor)
isequal(Gc1_factored,tf(C1))

factor =

1.3500

Gc1_factored =

0.4262 s + 0.3157

-----------------

s

Continuous-time transfer function.

ans =

logical

1

[Paul]

What is the definition of equality that you want to use for transfer functions?

As you just showed, the built-in isequal function appears to require that tf's have the same coefficients. But in order to use that definition you also have to specify another constraint, like the the leading coefficient of the denominator has to be unity.

What about this case:

>> G1=tf(1,[1 1])

G1 =
 
    1
  -----
  s + 1
 
Continuous-time transfer function.

>> G2=tf([1 2],conv([1 1],[1 2]))

G2 =
 
      s + 2
  -------------
  s^2 + 3 s + 2
 
Continuous-time transfer function.

For your application, would you want isequal(G1,G2) to evaluate to true or false?

[Bill Tubbs]

For my application (just checking that pidstd did what I expected) I would want it to evaluate True in your example (as @Walter Roberson's solution does). But since tf instances don't automatically cancel common factors (for obvious reasons), I think the current default behaviour of isequal is good. However, it would be nice if there was a way to simplify a tf or, as you suggest, simply set the leading coefficient of the denominator to unity. Then users could decide what manipulations to apply to either function prior to making the comparison.

[Paul]

Disclaimer: Only talking about SISO systems that don't have delays, though I think most if not all of this will exetend to systems with input or output delays.

If you're going to use Walter's approach, then you may need to account for some tolerance, as is always a concern when checking for equality. Here's an example where the difference between the two tf's should be zero, but they are not due to rounding. Depending on how you come up with your two tf's that you're comparing, this may or may not be of interest to you.

>> sys1=tf(rss(10));
>> sys2=sys1;
>> sys2.num{1}=sys2.num{1}*pi;
>> sys2.den{1}=sys2.den{1}*pi;
>> isequal(tfdata(sys1 - sys2), {0})
ans =
  logical
   0

Of course the difference is small.

>> [~,~,k]=zpkdata(sys2-sys1)
k =
   1.8094e-14

Making your decision on equality based on k is probably the better way to go if you're deriving two tf's that should be equal in principle but aren't equal numerically.

As for normalizing the leading coefficient of the denominator, either do it the manual way as you did above or convert your tf to one of the other forms and convert back:

>> sys1=tf(3,3*[1 1]);
>> tf(zpk(sys1))
ans =
 
    1
  -----
  s + 1
 
Continuous-time transfer function.

If you go down this route, you might as well just leave it in the zpk form, unless you really need a tf for some reason. Keep in mind that the double conversion could yield slightly different coefficients than the manual approach due to rounding effects in the conversion algorithms.

See doc minreal if by "simpiify a tf" you mean get rid of poles and zeros that (should) cancel. Hey, I just discovered that minreal also simplifies the gain.

>> minreal(sys1)
ans =
 
    1
  -----
  s + 1
 
Continuous-time transfer function.

I haven't checked the inner workings of minreal so don't know if that's a preferred approach to get that leading coefficient to one.

[Bill Tubbs]

Thanks Paul. I did not know about zpk or minreal and they will for sure be useful for these type of tf manipulations.

[Bill Tubbs]

I think it's worth highlighting that if using zpk during the equality check, it's important to also convert back to tf before the subtraction as Paul says in comment above. Otherwise, you can get some numerical errors creeping in.

E.g.

>> zpk(tf(1,[2 1])) - zpk(tf(1,[2 1]))

ans =
 
  1.1102e-16
  ----------
  (s+0.5)^2
 
Continuous-time zero/pole/gain model.

whereas

>> tf(zpk(tf(1,[2 1]))) - tf(zpk(tf(1,[2 1])))

ans =
 
  0
 
Static gain.

Something to do with how subtraction is handled for zpk objects compared to tf objects perhaps.

Answer 3

[Bill Tubbs]

Based on comments from Paul above I offer these functions as a solution:

function c = is_equal_tf(G1,G2)
    c = almost_zero_static_gain_tf(G1 - G2);
end

function c = almost_zero_static_gain_tf(G)
    [~,~,k] = zpkdata(G);
    c = abs(k) < 1e-10;
end

Obviously, doesn't work with delays.

It passes the following tests:

assert(is_equal_tf(tf('s'),tf('s')))
assert(is_equal_tf(tf(1,1),tf(-1,-1)))
assert(is_equal_tf(tf(2,[2 1]),tf(1,[1 0.5])))
assert(~is_equal_tf(tf(2.1,[2 1]),tf(1,[1 0.5])))
assert(is_equal_tf(tf(2,conv([2 1],[5 1])), tf(2,[10 7 1])))
assert(~is_equal_tf(tf(2,conv([2 1],[4 1])), tf(2,[10 7 1])))
assert(is_equal_tf(tf(1,[2 1]) - tf(1,[5 1]), tf([3 0],[10 7 1])))
assert(is_equal_tf(pidstd(0.42,1.35), 0.42*(1+1/(1.35*tf('s')))))
G1=tf(rss(5)); G2=G1;
assert(is_equal_tf(G1, G2))
G2.num{1} = G2.num{1}*pi;
G2.den{1} = G2.den{1}*pi;
assert(is_equal_tf(G1, G2))

Any exceptions or other cases I should test?

[Paul]

What result do you expect for this case:

G1=tf(1e-11);
G2=tf(1e-11,[1 0]);

Out of curiosity, what is the motivation behind this exercise?

[Bill Tubbs]

The motivation is to check transfer function manipulations done by hand-for homework submissions! For example, I must calculate the following result:

G11 = tf(1,[5 1]);
G12 = tf(1,[22 1]);
G21 = tf(0.6,[5 1]);
G22 = tf(1.2,[10 1]);
G1 = G11 - G12*G21/G22

By hand I get the following for G1:

But the MATLAB script above produces:

G1 =

102 s^2 + 23.4 s + 0.6

--------------------------------

660 s^3 + 294 s^2 + 38.4 s + 1.2

So, I want to check these are equal by doing:

is_equal_tf(tf(0.5*[34 1],conv([5 1],[22 1])),G1)

In my case, all the coefficients are going to be 'sensible' values not extremely small or large. If there is any easier way to do this please let me know!

[Paul]

Well, based on my own experience you never know what a student will submit ;).

I'm not aware of any built-in way to display the transfer function in the form of (as+1)/(bs+1). You could probably write your own, but probably not worth it.

I suppose another alternative that doesn't rely on comparing transfer functions algebraically would be to come up with some criteria on the difference between the impulse responses for the two cases.

[Bill Tubbs]

The only way I know is to do it symbolically. There's a nice pair of functions, tf2sym and sym2tf in this package by Oskar Vivero Osornio to convert to/from symbolic functions. Then you can get it in a form where they are comparable by eye, as you suggest:

>> tf2sym(G1)
 
ans =
 
(34*s + 1)/(220*s^2 + 54*s + 2)
 
>> factor(tf2sym(G1))
 
ans =
 
[ 1/2, 34*s + 1, 1/(5*s + 1), 1/(22*s + 1)]
 

The thing I don't like with this approach is the need to continually switch between tf and symbolic, always redefining s in the same script.