Thanks for posting your file, it contains a lot of useful functions.
When I run it, MathCAD 15 returns an error and here is the trace I did:
Can you explain what is wrong?
I don't have v15, but I have a reasonable guess. If you look at the beginning of the Z2RCladder area, I define a function Stack, which accepts NaN (not a number). This acts as a NULL number. V11 allows for it; I don't know if v15 does or not. In any case, the object of Stack is to allow use of cases such as Stack(NaN, vec), which simply returns vec, the non-NaN argument. The built-in function stack in v11 gives an error in this case; it requires both arguments to be arrays of appropriate dimensions. I don't know if this hold true in v15.
This behavior is useful when iterating calculations through a number of values, and want to append the result of the most recent cal to the existing array. By setting the initial value to NaN, the the initial calc (with no preceding calc values to append to) does not need to be treated/programmed as a special case.
If you can find an alternate way to implement Stack, then simply replace my original definition. The revised file attached goes another route.I implemented a second version of the Z2RCladder function, in which I initialize the RC array to (0 0) instead of NaN. This results in an extraneous first row in the output array, which is removed before returning the RC values.
Sure, here she is.
Brainthaw: OP=Original Poster.
You can only attach one file to a (new) post or answer. To attach a second file, you have to edit your existing posting...
You can only attach one file to a (new) post or answer.
Not exacly true. You CAN attach multiple files already in your first attempt but they must all be marked/highlighted at once. Once you have attached a file (or a couple of files) you cannot add more attachments but must post your answer and then edit it again.
The statement is my (Mathcad) implementation of the Matlab: Nnew = N*D(1)-[D 0]*N(1);
It would mean that the source is incorrect...
I don't think the source is incorrect.
In the highlighted line, I calculated the reminder and the s^5 should have go away but It didn't because of floating point residues. In the next line, to work around, I used the s^5 of the numerator plus the denominator minus its s^4 times the quotient, in the calculation of the reminder.
I thought that maybe the same thing happened in your file at:
I think that all the math in your function NumDen2Cauer is correct. Also, the submatrix operations throw out the terms that are expected to be zero, so any nonzero residual value from incomplete cancellation doesn't matter. This function and my implementation agreed in all cases when given the same coefficient vectors. To be completely general, you could allow for the cases 1) that have an input resistance & no shunt capacitance, resulting in num and denom polynomials having the same order. The routine as is doesn't allow for this. Need to jump to the R calc as the first value calculated, then resume with C-R-C-R..., and 2) where there is no shunt R at the end (DC open circuit, or Rend = infinity). In this case, the den polynomial has zero constant term, so Z has a pole at s=0.
The calc errors come from the symbolic calculation of the num and denom coefficients. I set up your symbolic function which just returns the coefficients, and did not include the NumDen2Cauer function. Strangely, for cubic or higher order polynomials, the set of coefficients for a polynomial is correct, but they appear in an incorrect order - they are permuted.
I played with splitting up the symbolic calc, and wound up with a sequence I call step-by-step symbolics (see images). This worked for all the examples I tried, up to the eighth order example. In the image, the errors for a third and fourth order terms can be seen in the one step calc, while the step-by-step symbolics and my numeric calc give the correct answers.
One observation concerns me. Using the real (decimal) values of the eighth order example, the symbolic coefficients get quite big, ~10^85. I guess that the symbolic engine is converting the real numbers to rational fractions and working from there. I have found a few simple decimal RC inputs for which the coeff calc didn't work at all.
The v11 file with the new examples is attached.
Thank you very much Lou, for sorting that out.
I've trusted the symbolic results too much. Now, once more, this shows that it is hard, to impossible, to control the output (shape) of symbolic results. That can have, and in this case has, a serious impact on obtained results.