control package, odd behavior multiplying tf's

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

control package, odd behavior multiplying tf's

nrjank
working with chains of some rational MIMO transfer functions. get some very different results based on order of multiplication. without knowing too much of what's going on under the hood, wonder if someone can explain if this is expected or not:

sample tfs:

>> a1 = tf({[2 24],[12];[1 48 0],[2 24]},{[-1 24],[-1 24];[-4 96],[-1 24]});
>> a2 =a1; a3 = a1; a4 = a1;

this produces the expected series answer, nicely simplified
>> a1*a2*a3*a4

so does this, doing one multiplication at a time:
>> a1*a2;ans*a3;ans*a4

since matrix multiplication is associative, (and since the tfs are identical) this should also work
>>a3*a4;a2*ans;a1*ans
but the result is very different

also happens with different, unequal tfs. is there something about having the more complex tf as the second term for the multiply?

checking against ML2015. ML doesn't try to do any rational simplfication, so it's a bit of a mess with very high polynomial order doing any of the above steps. using minreal between each step keeps it on track and the answer matches the expected analytical result multiplying in any direction.

So, what is up with Octave's result for the 3rd case?

(using 4.0.0 on windows with control-2.8.1)

nickj

_______________________________________________
Help-octave mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/help-octave
Reply | Threaded
Open this post in threaded view
|

Re: control package, odd behavior multiplying tf's

Doug Stewart-4


On Fri, Jun 12, 2015 at 3:55 PM, Nicholas Jankowski <[hidden email]> wrote:
working with chains of some rational MIMO transfer functions. get some very different results based on order of multiplication. without knowing too much of what's going on under the hood, wonder if someone can explain if this is expected or not:

sample tfs:

>> a1 = tf({[2 24],[12];[1 48 0],[2 24]},{[-1 24],[-1 24];[-4 96],[-1 24]});
>> a2 =a1; a3 = a1; a4 = a1;

this produces the expected series answer, nicely simplified
>> a1*a2*a3*a4

so does this, doing one multiplication at a time:
>> a1*a2;ans*a3;ans*a4

since matrix multiplication is associative, (and since the tfs are identical) this should also work
>>a3*a4;a2*ans;a1*ans
but the result is very different

also happens with different, unequal tfs. is there something about having the more complex tf as the second term for the multiply?

checking against ML2015. ML doesn't try to do any rational simplfication, so it's a bit of a mess with very high polynomial order doing any of the above steps. using minreal between each step keeps it on track and the answer matches the expected analytical result multiplying in any direction.

So, what is up with Octave's result for the 3rd case?

(using 4.0.0 on windows with control-2.8.1)

nickj

_______________________________________________
Help-octave mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/help-octave



I confirm your results.

I also tried a SISO system

 a3=tf( [2 24],[1 4 7] )
 a4=a3*a3
 a5=a3*a4
 a6=a4*a3
but this worked correctly.

a simpler example of your equation is:
 a1 = tf({[2 24],[12];[1 48 0],[2 24]},{[-1 24],[-1 24];[-4 96],[-1 24]});
a2=a1*a1;
a3=a2*a1
a4=a1*a2

 

--
DAS


_______________________________________________
Help-octave mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/help-octave
Reply | Threaded
Open this post in threaded view
|

Re: control package, odd behavior multiplying tf's

nrjank


>
> I confirm your results.
>
> I also tried a SISO system
>
>  a3=tf( [2 24],[1 4 7] )
>  a4=a3*a3
>  a5=a3*a4
>  a6=a4*a3
> but this worked correctly.
>
> a simpler example of your equation is:
>  a1 = tf({[2 24],[12];[1 48 0],[2 24]},{[-1 24],[-1 24];[-4 96],[-1 24]});
> a2=a1*a1;
> a3=a2*a1
> a4=a1*a2
>
>  
>
> --
> DAS
>

Thanks Doug. So, bug? Or some expected behavior I do not fathom yet?


_______________________________________________
Help-octave mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/help-octave
Reply | Threaded
Open this post in threaded view
|

Re: control package, odd behavior multiplying tf's

sshah
Nothing in floating point arithmetic is really associative; only within numerical conditioning bounds.

Perhaps you are creating a Jordan structure, connecting identical  tf chains in series, and blowing up the matrix conditioning.   

Check the conditioning of the eigenvectors system matrix of the series connected system to see if this is the case.  

If each of the series connected system is numerically different, this problem goes away.  

Sunil Shah


On Fri, Jun 12, 2015 at 9:11 PM, Nicholas Jankowski <[hidden email]> wrote:


>
> I confirm your results.
>
> I also tried a SISO system
>
>  a3=tf( [2 24],[1 4 7] )
>  a4=a3*a3
>  a5=a3*a4
>  a6=a4*a3
> but this worked correctly.
>
> a simpler example of your equation is:
>  a1 = tf({[2 24],[12];[1 48 0],[2 24]},{[-1 24],[-1 24];[-4 96],[-1 24]});
> a2=a1*a1;
> a3=a2*a1
> a4=a1*a2
>
>  
>
> --
> DAS
>

Thanks Doug. So, bug? Or some expected behavior I do not fathom yet?


_______________________________________________
Help-octave mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/help-octave



_______________________________________________
Help-octave mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/help-octave