Functions to access to numerator and denomerator of tf

[mfalt]

From @baggepinnen on February 21, 2016 12:28

e.g. numerator = num(G) and num,denom = poly(G)

Copied from original issue: mfalt/Control.jl#12

[mfalt]

What would be the result of this, a Transferfunction, or a Polinomial? And how do we handle the fact that transferfunctions by default are MIMO systems, only allow it for siso systems?

[mfalt]

From @baggepinnen on February 21, 2016 13:17

I often find the fact that all TFs are MIMO systems confusing. This is not the case in matlab, and it causes a lot of unexpected behaviour. The boxing and unboxing required to convert between scalars and arrays is very confusing in the beginning, and annoying in the end. Students with little or no julia experience will not find the error messages very helpful in the beginning.

The result could be an array of polynomials in the MIMO case. In the siso case, I would like a polynomial, not a one element array of polynomials, which I acknowledge is a strange special case behavior.

[mfalt]

My proposal is that we do the following three things:

• Deprecate "Base.num" and "Base.den" for SISO types
• Implement numvec/denvec which returns vectors of the polynomial coefficients as represented in sisotf (and throw error for sisogeneralized).
• Implement numpoly/denpoly that returns a Polynomials.Poly in the same way as above.

I will implement this soon if no one disagrees. I will at the same time go through the code and replace any reference to sys.num / sys.den that is not appropriate.

[aytekinar]

@mfalt what is the situation for this one? do you need help with numvec/denvec and numpoly/denpoly ? I will be needing them for dcgain when adressing your comments in #56

[mfalt]

I was hoping for some input first. But I can try to do this during the weekend/next week.

[mfalt]

@aytekinar It is implemented now in branch numden #57, I will pull it into master when I have verified it.

[aytekinar]

@mfalt I have seen it and have checked myself and given some minor comments. I can rebase my dcgain branch on numden and push my changes accordingly, or else, I can wait until it is on master. anyways dcgain is tagged for v0.2 milestone, which is due by the end of the month.

[mfalt]

Great, I'll look at them, I think you could either rebase and use the numvec functions, or if you want to use the polyomials, wait until I change the inplementation to Polynomials.jl, which I think will be done this week.

[aytekinar]

I think I don't need polynomials if I am to use the numpoly, etc functions. So I will be rebasing on numden.

[mfalt]

The point is that numpoly currently returns our own Poly and will soon be returning a Polynomials.Poly, so if you are accessing the elements in a polynomial it will differer. So it may be better to use numvec/denvec or alternatively calling poly2vec which I will keep current.

[aytekinar]

Yep, I know. I will try using vecs instead. In the worst case scenario, I am counting on the continuous integration :)

[mfalt]

Great, yes the test are pretty good by now. You can also test it locally by running Pkg.test("ControlSystems") You might not pass the tests on plotting though, which we should try to improve.

[baggepinnen]

See numvec, numpoly, denvec, denpoly