Re: [Maxima-discuss] solve() involving sqrt()

[Me S. <vla...@gm...>]

Hello Richard

The results are fine. The difference between x and y should be about
four orders of magnitude. If you want to compare, consider H(s) the
reference transfer function (evaluate with H(s)/H(0)*4/4.1) and G(s)
this one:

H(s):=(s^2+98.756)/(s^2+1.0915*s+1.1081)$

G(s):=(360*s^2*sqrt(x*y)*z+400)/(s^2*(369*sqrt(x*y)*z+(10*y+400*x)*z)+s^3*(sqrt(x*y)*90*y+90*x)*z+100*x*y*z)+s*(40*z+100*y+100*x)+410)$

If it makes it easier, consider x=L1, y=L2, and z=C1 in a T LC
lowpass, with the two L coupled (Rin=0.1, Rout=4):

--*L1--.--L2*--
       C1

The workaround for the sqrt() was because it looked like
minpack_solve() wouldn't solve it, but I handled it wrong (I
apologized before, but I'll do it again).

> I don't understand ... plugging those values in for x,y,z from minpack
> with starting point 1,1,1
> gives rather large values,
> e.g. eq1 is about 5.74. at the solution.
>
> The results of solve (after appropriate squaring) from the solution I
> posed, gives results
> like 10^(-10). ...
>     [-5.474334493507415*10^-12,  3.548218062681546*10^-10,
> 2.090438133731456*10^-9]
>
>
> I assume more digits could be obtained by using a higher precision
> polynomial
> zero-finder at the point in the algorithm that this system of equations
> is reduced to a polynomial
> in one variable. But I sort of thought the answers would be good for a
> few decimal places.
> I
> I thought that feeding the results I found, namely
>
> (%o24)  [x=3.857950974230044,y=4.622955406728833*10^-4,z=0.2397720333808264]
>
>   into minpack  as a starting point, would result in about the same
> numbers returned..
>   Instead resulted in the rather different set
>
> (%o30)
> [[4.034938214233187,4.835038247043442*10^-4,0.2292547490241119],2.815769270875939*10^-15,1]
>
> and when the 3 values for x,y,z were put back into eq1,2,3
> the result was even better...
>
> (%o31)    [-1.110223024625157*10^-15,  0.0, 2.58765558419226*10^-15]
>
> Is this problem especially ill-conditioned?  one set looks like
> [3.8,4.6e-4,0.24]  the other [4,0, 4.8e-4, 0.23]
> I did not expect them to differ in the 2nd or 3rd decimal place.
>
> These answers are not particularly close to the results cited below,
> starting at 1,1,1.


Regards,
Vlad