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

[Raymond T. <toy...@gm...>]

On Mon, Sep 14, 2020 at 2:38 PM Richard Fateman <fa...@cs...>
wrote:

> 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.
>

Heh. I didn't check that the return code is 4, meaning it's not making good
progress.  I was more focussed on the error that was reported and not the
actual results.

>
> 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.
>
>
> RJF
>
>
>
>
>
>
> On 9/14/2020 8:42 AM, Raymond Toy wrote:
> >
> >
> > On Mon, Sep 14, 2020 at 8:32 AM Me Self <vla...@gm...
> > <mailto:vla...@gm...>> wrote:
> >
> >     > What starting points did you use?
> >     >
> >     > I got:
> >     >
> >     > minpack_solve([eq1,eq2,eq3],[x,y,z], [1,1,1]);
> >     > Evaluation took 0.0100 seconds (0.0100 elapsed) using 942.305 KB.
> >     >
> >     > [[5.740409864561979,-1.755503737103853,0.1624466869294288],
> >     >  0.01024886625263842,4]$
> >
> >     So do I, now. In fact, with a bit of tuning, it solves it just fine.
> I
> >     think this happened because of the previous actions, I probably
> should
> >     have used kill() before switching to minpack_solve(). I apologize for
> >     the noise.
> >
> >
> > If you can reproduce the issue, it would be nice to know; maybe some
> > check can be added to give a much better answer than just some random
> > lisp type error.
> >
> >
> >
> >     Regards,
> >     Vlad
> >
> >
> >
> > --
> > Ray
> >
> >
> > _______________________________________________
> > Maxima-discuss mailing list
> > Max...@li...
> > https://lists.sourceforge.net/lists/listinfo/maxima-discuss
>
>
>
> _______________________________________________
> Maxima-discuss mailing list
> Max...@li...
> https://lists.sourceforge.net/lists/listinfo/maxima-discuss
>


-- 
Ray