MaplePrimes - answers and comments on Question, Finding solutions with less accuracy

precision and accuracy

acer — Wed, 06 Feb 2013 05:02:05 Z

It's not clear, right now, that you know for sure that there is in fact a root with a1:=1.514 and a2:=5.049. Perhaps you are willing to allow a small violation of the equations, in which case those could be constraints of an optimization problem for which you'd likely need a global solver.

It might be interesting to see how the other variables change, w.r.t. a1 and a2, near the previous full precision root you cited.

In your earlier thread, Carl Love mentioned controlling accuracy and precision separately. I too had been working along those lines, to investigate. I did not find a root, but it's not clear whether that is because the ranges are so great, or the functions are so nonlinear, or perhaps there is no root for those chopped a1 and a2 values.

Anyway, here is one way to have the evaluations done at higher precision while still allowing fsolve to do its usual thing and compute an accuracy tolerance based on the inbound Digits value.

restart:

read "Cvector_with_a.m":

Cnew:=eval(C,[a1=1.514,a2=5.049]):

for i from 1 to 9 do
   Cproc[i]:=codegen[optimize](
                unapply(Cnew[i],[indets(Cnew[5],name)[]])):
end do:

save Cproc, "Cproc.m":  # you only ever want to do this once

And then,

restart:

read "Cproc.m":

for i from 1 to 9 do
   f[i]:=subs(counter=i,proc(cc,C1,C2,C3,C4,C5,C6,C7,HB)
      Digits:=100:
      Cproc[counter](cc,C1,C2,C3,C4,C5,C6,C7,HB);
   end proc);
end do:

Cproc[5](1.0,
         246.851, 9.597, 7.153, 56.14, 18.91, 2.656, 7.73,
         0.012);

                                              11
                              -0.9931016321 10

f[5](1.0,
     246.851, 9.597, 7.153, 56.14, 18.91, 2.656, 7.73,
     0.012);

-0.992357302391520534067512587085549339330928664664135982173091890590934784\

                                   11
    6556567851795358311687275614 10

and so on. Of course not all those decimal digits in the result from f[5](...) above are correct. But hopefully there are enough correct (more than from Cproc[5] called at default working precision, anyway) to allow a numerical solver to get a grip and converge if it can.

The procedures f[i] use the codegen[optimized] procedures's formulas -- by virtue of calling Cproc[i] -- but they each temporarily raise Digits to 100 before making those calls.

You can then try feeding those to a rootfinder (or global optimization scheme, if that's what you want). And you could replace the hard-coded 100 by some name, so that the higher working precision was under your control.

acer

A Start with Optimization

John May — Wed, 06 Feb 2013 18:45:17 Z

Sometimes Optimization is able to do something with overconstrained systems. One way to try this is:

   read("Cvector_with_a.m"):
   infolevel[Optimization]:=4;
   Optimization:-Minimize(1,{seq(C[i]=0, i=1..9), c1>=1,c<=900,c2>=1,c2<=900,
c3>=1,c3<=900,c4>=1,c4<=900,c5>=1,c5<=900,c6>=1,c6<=900,c7>=1,
c7<=900,hb>=0.01,hb<=900, a1>=1.5, a1<=1.6, a2>=5,a2<=5.1},
feasibilitytolerance=10^(-3), iterationlimit=1000, initialpoint=[a1=1.52, a2=5.04,
c=1,hb=0.012,c1=46.9, c2=9.60, c3=7.15,c4=56.1,c5=18.9,c6=2.65,c7=7.74]);

Unfortunately, that does not appear to converge on a solution. You could play around with the various ?Optimization,Minimize options, the linear constraints on the variables, and the precision of the initial point. You can also move the C[i]=0 constraints to the objective function and try that instead. One of these might work for you.

Good Luck,

John

Lack of procedure knowledge

PatD — Wed, 06 Feb 2013 21:12:38 Z

Acer, thanks for the reply. However Maple procedures are very new to me and I would like a little clarification. In the first set of code I don't understand what this means within the unapply brackets:

[indets(Cnew[5],name)[]] I personnally would have gone along the lines of [c, c1, c2, c3, c4, c5, c6, c7, hb].

Also, for the second set of code, I have no idea what is going on here:

Cproc[5](1.0,
         246.851, 9.597, 7.153, 56.14, 18.91, 2.656, 7.73,
         0.012);

                                              11
                              -0.9931016321 10

f[5](1.0,
     246.851, 9.597, 7.153, 56.14, 18.91, 2.656, 7.73,
     0.012);

-0.992357302391520534067512587085549339330928664664135982173091890590934784\

                                   11
    6556567851795358311687275614 10

Thanks!

Pat

raising working precision

acer — Wed, 06 Feb 2013 23:34:30 Z

@PatD The procedure Cproc[5] evaluates the 5th expression from your `C` (for those fixed a1 and a2 values you gave), following production from that of an optimized procedure. When Cproc[5] is called, its arguments are used as values for the remaining varaibles (given that a1 and a2 have been fixed).

The procedure f[5] also accepts the same kind of arguments as Cproc[5]. In fact, all that f[5] does is raise the working precision (Digits) and then pass the arguments on to a call to Cproc[5].

Digits is an environment variable, and as such will be inherited in the call to Cproc[5] done within f[5]. So f[5] is just a slick way to get Cproc[5] to compute at higher working precision without having to raise Digits at the top level.

I gave an example, where one can see that f[5] and Cproc[5] return results that differ in something like the 3rd decimal digit. This shows what you said, that the expressions are sensitive to working precision. Hopefully the result from f[5] is accurate enough.

And similarly, for all the f[i] and Cproc[i] for i=1..9.

I created such f[i] because of what Carl mentioned about fsolve. When you call fsolve it has to figure out its stopping/acceptance criteria. It bases that on the number of variables and on Digits. If you want your expressions to get evaluated at high working precision (b/c of roundoff error or numerical instability) then the temptation is to just raise Digits high at the level from which you call fsolve. But raising Digits high at that level will cause fsolve to use a much tighter accuracy/acceptance, which again does not get met. It's a push-me/pull-me dichotomy. What fsolve does not offer are options to raise its working precision to a user-specified value while also forcibly keeping the accuracy requirements low. A problematic scenario is one in which the value of Digits where fsolve is called is never high enough a working precision for the expression evaluations to allow the accuracy tolerance of fsolve (based on that same Digits value) to be met.

And that's where the f[i] come in. Using them as replacements to the Cproc[i] we can cause the expressions to be evaluated numerically at high working precision while allowing fsolve to still use the lower Digits setting (at the outer level at which its called) and thus make far less demands for acceptance of a root.

The idea is to leave Digits as it is, say 10 the default value. Then call fsolve and use the f[i]. Internally, fsolve will try and meet an accuracy acceptance tolerance based on Digits=10. And that will likely never succeed unless the individual expressions can be numerically evaluated as something near 10-digits accurate or so. And such accuracy for the numerical evaluations of the expressions may require a very high working precision indeed. (You make wish to experiment with that formation of the f[i], to see just high they have to locally set Digits.)

This all assumes that fsolve is being called with its first argument as a set of procedures, rather than a set of expressions. Hence the parameter ranges are supplied like [...,1..900,...] instead of [...,c3=1..900,...] etc. This is similar to how `plot` and `Optimization` routines differ for ranges, according to input in procedure or expression form.

Hey John, Thanks for the procedure,

PatD — Fri, 08 Feb 2013 20:04:30 Z

Hey John,

Thanks for the procedure, I have been testing it with only 1 equation. It would appear that the optimization algorithm is having trouble because it is trying to minimize to the smallest possible value and for maple that is the largest negative value it can find. Whereas I am trying to find the values which produce a solution as close to zero as possible regardless of whether or not that solution is positive or negative. Here is my code, suggestions? Also it is inclear to me what "infolevel" does exactly.

read "Cvector_with_a.m";
infolevel[Optimization] := 4;
                               4
Digits := 30;
                               30
a1 := 1.514; a2 := 5.049;
                             1.514
                             5.049
Optimization[Minimize](C[2], {c >= 0, c1 >= 1, c2 >= 1, c3 >= 1, c4 >= 1, c5 >= 1, c6 >= 1, c7 >= 1, hb >= 0.1e-1, c <= 2, c1 <= 900, c2 <= 900, c3 <= 900, c4 <= 900, c5 <= 900, c6 <= 900, c7 <= 900, hb <= 0.2e-1}, iterationlimit = 1000000, initialpoint = [c = 1, hb = 0.1e-1, c1 = 1, c2 = 1, c3 = 1, c4 = 1, c5 = 1, c6 = 1, c7 = 1]);
     NLPSolve: calling NLP solver
     NLPSolve: using method=sqp
     NLPSolve: number of problem variables 9
     NLPSolve: number of nonlinear inequality constraints 0
     NLPSolve: number of nonlinear equality constraints 0
     NLPSolve: number of general linear constraints 18
     NLPSolve: feasibility tolerance set to 0.1e-14
     NLPSolve: optimality tolerance set to 0.2511886432e-21
     NLPSolve: iteration limit set to 1000000
     NLPSolve: infinite bound set to 0.10e21
     NLPSolve: trying evalf mode
     attemptsolution: iterates did not converge, but first-order conditions have been met
     attemptsolution: number of major iterations taken 7

[-1.23389380823272547574498378184 10^24 , [
             c = 2.00000000000000000000000000000,

             c1 = 900.000000000000000000000000000,

             c2 = 900.000000000000000000000000000,

             c3 = 900.000000000000000000000000000,

             c4 = 900.000000000000000000000000000,

             c5 = 900.000000000000000000000000000,

             c6 = 900.000000000000000000000000000,

             c7 = 900.000000000000000000000000000,

hb = 0.0200000000000000000000000000000]]

Thanks,

Pat