The problematic floating-point computation is encountering roundoff error, due to the forced low working precision induced by the call,
    evalf(..., 5)

Do not lower working precision just to produce a numeric formatting effect. That is very much not a good way to do numeric computation in Maple.

It is usually inadvisable to lower working precision down to 5, for almost all nontrivial computations.

If you really want your numeric results rounded to 5 significant places then assign the computed results to some name, and then apply something like evalf[5] to that. Then display or assign that, as your choice.

Or just set the displayprecision (using the interface command or Tools/Options in the GUI), although in some versions there is difference between trailing digits (after the decimal) and the number of displayed digits. I do not think that the GUI always does it usefully.

Note. The syntax evalf(...,5) is inferior to the syntax evalf[5](...) , since the former is awkward if the expression is itself an expression sequence. I am not suggesting that you simply replace one with the other as the solution to your problem. You should not wrap either around your computation.

I don't have much time today to look at this, sorry, but judging only from the followup comment made to Tom, I'd like to ask this:

    In order to reduce the memory cost couldn't procedure P admit
    (premade) Matrix X as an additional argument and then act
    on it "inplace"?

The procedure P could optionally call ArrayTools:-Fill, if it was strictly required to "zero out" X at the start of each call.

The higher level code which called P could be done with two statements, in the case that separate result Matrices were needed conconcurrently. Ie,  Y:=Matrix(..) and then P(...,Y).

Note the for the task of repeatedly calling P(...,X) many times there is not just the possible savings in memory space cost. There can also be considerable time cost savings since garbage collection (memory management overhead) costs to clean up all the "discarded, unreferenced, prior" separate returned Matrices is alleviated. It takes time to do garbage collection.

This is a stock technique for improving performance. For example, an optional "inplace-container" procedure-parameter was added to Statistics:-Sample for these same reasons. That command can be passed an extra rtable argument, into which the sample is written.

Look at how your procedure assigns to uvp at the end of its loop.

Your procedure did it differently than you had it in the top-level code, ie. a list of equations like name=number.

I didn't search for other discrepencies in the uncommented procedure.

faq_ac.mw

The error message seems clear: you passed Data to subs (and not as the last argument, the expression to be changed) but it is not an equation (or a sequence or list of set of equations).

Perhaps you have mistakenly tried to use the mere name Data for this subs call, even though Data has not actually been assigned anything? Or perhaps(?) Data was assigned a table?

Why not upload and attach a worksheet that reproduces the problem?

You haven't told us whether you're trying to do a global or local search.

[edit. You didn not clearly explain just why the varying results are problematic for you. One reasonable interpretation -- in the absence of an explanation -- is that the central issue is that sometimes the results are suboptimal, and that you are looking for a best result -- or consistently very close to it. If that is not the central issue then you really ought to explain the difficulty more clearly.]

You could trying adjusting the options (especially those which the DirectSearch Help pages describe as affecting reliability and accuracy).  See especially the options checkexit and timelimit, and if you choose to use its GlobalSearch command then also the number option.

Read the relevant DirectSearch help pages carefully. The options are there because, as a general rule, global optimization of difficult problems can produce a solution whose quality depends on how hard and for how long you make it work. That's not specific to the DirectSearch package or Maple -- it's true of numeric global optimization in general.

Another possibility is to adjust some code I once wrote for automating repeated calls to the DataFit command of DirectSearch -- although you may well find that for using its GlobalOptima command the number option suffice to produce similar or better benefit.

restart;

kernelopts(version);

    Maple 2020.0, X86 64 LINUX, Mar 4 2020, Build ID 1455132

ans := convert( int(arccos(x)*arcsin(x),x), arcsin );

                    /                       (1/2)\                     
               1    |              /  2    \     |            2        
        ans := - Pi \x arcsin(x) + \-x  + 1/     / - arcsin(x)  x + 2 x
               2                                                       

                                  (1/2)
                         /  2    \     
           - 2 arcsin(x) \-x  + 1/     


simplify(convert( diff(ans,x) - arccos(x)*arcsin(x), ln) );

                               0

Executing a restart will cause the Startup Code to be re-executed.

Perhaps you worksheet contains a restart statement.

You could also use plots:-listplot for this. For example, using your definition:

plots:-listplot([seq(b(i),i=1..10)],
                color=red);

plots:-listplot([seq(b(i),i=1..10)],
                color=red,style=point,symbol=solidcircle);

You could, of course change the style and size of those plots.

See also here, where you could divide by the suitable power of 2.

The names a,b,c inside the procedure f are global names. The a,b,c in the call to solve within PARB2 have been declared as local. These are not the same names.

The names in the expressions returned by f (and assigned to gl1,gl2 within PARB2) are the global names. But the names in the set passed as the second argument to solve inside PARB2 are different, as they are local names. So inside PARB2 that call to solve is requesting solutions for names that don't actually appear inside the expressions assigned to gl1,gl2.

You could fix this mistake in several ways, including:
1) Don't declare a,b,c local to PARB2. eg. proctes_ac1.mw
or,
2) Inside PARB2, substitute global a,b,c in generated expressions assigned to gl1,gl2 with local a,b,c prior to calling solve.
or,
3) Recreate f within PARB2, using local a,b,c.
or,
4) Pass the names of the parameters a,b,c from the outer scope as additional arguments to PARB2, and use them in the solve call instead.
or,
5) Omit the second argument to solve as called within PARB2 eg. proctes_ac5.mw

I cannot tell which correction you would prefer. I haven't bothered to code all the above.

@woolyabyss The Online Help allows you to check for topics/commands not available in your older version.

For example, the online Help page for Topic dataplot shows the version in which it was released in its Compatibility section.

As for handling your data in Maple 17, you can plot a single Vector V using the command
   plots:-listplot( V )
You can could create a plot from two numeric Vectors X and Y with the command
   plot( <X|Y> )
And you can combine plots using the plots:-display command.

restart;

L:=1: c:=2: g:=0:
f:=(8*x*(L-x)^2)/L^3:
pde:=diff(u(x,t),t$2)=c^2*diff(u(x,t),x$2):
bc:=u(0,t)=0,u(L,t)=0:
ic:=u(x,0)=f,D[2](u)(x,0)=g:

sol:=pdsolve([pde, ic, bc],u(x,t)):

sol15:=rhs(subs(infinity=15,sol));

plots:-animate(plot,[sol15, x=0..1],t=0..1,frames=100);

This kind of question has been asked before, with several approaches given at various times (eg. here, here). 

Here are some examples.

restart;

ee := cos(Pi/16);

                                 /1    \
                        ee := cos|-- Pi|
                                 \16   /

s := Pi = v*16;

                         s := Pi = 16 v

eq := map(cos, s);

                      eq := -1 = cos(16 v)

E := expand(eq);

                        16                14                12
  E := -1 = 32768 cos(v)   - 131072 cos(v)   + 212992 cos(v)  

                    10               8               6
     - 180224 cos(v)   + 84480 cos(v)  - 21504 cos(v) 

                  4             2    
     + 2688 cos(v)  - 128 cos(v)  + 1


S := {solve(E, cos(v), explicit)}:

F := select(r->is(r=ee), S)[1]; # or test using float approximation

                                            (1/2)
                     /            (1/2)    \     
                   1 |/     (1/2)\         |     
              F := - \\2 + 2     /      + 2/     
                   2                             

# Here is your answer.
ee = F;
                                                (1/2)
                         /            (1/2)    \     
             /1    \   1 |/     (1/2)\         |     
          cos|-- Pi| = - \\2 + 2     /      + 2/     
             \16   /   2                             

# Various checks are possible. Here are some
# crude examples.

evalf(%);

                  0.9807852804 = 0.9807852805

is(ee = F);

                              true

convert_radical_example.mw

Here is another (though the call to factor might require a radical extension for other examples, which we might be able to obtain using, say, evala(Subfields(...)) ).

restart;
P:=op(1,convert(cos(Pi/16),RootOf));
                    8         6         4        2    
         P := 128 _Z  - 256 _Z  + 160 _Z  - 32 _Z  + 1

Rs:=simplify(radnormal~([solve(factor(P),explicit)]),size):
R:=select(r->is(r-cos(Pi/16)=0),Rs)[1];
                                            (1/2)
                     /            (1/2)    \     
                   1 |/     (1/2)\         |     
              R := - \\2 + 2     /      + 2/     
                   2                             

simplify(R-cos(Pi/16));
                               0

convert_radical_example2.mw

Firstly, you could read the appropriate Help pages, for example those wtih topic:
  dsolve,numeric/BVP
and
  dsolve,numeric_bvp,advanced

Next, you could try running your example with the appropriate infolevel set. For example (and, assuming that the incomplete example you provided is actually part of some boundary-value problem),

restart;
kernelopts(version);
    Maple 18.02, X86 64 LINUX, Oct 20 2014, Build ID 991181
ode := 1/100*diff(y(x),x,x)+exp(y(x))*diff(y(x),x)
       -1/2*Pi*sin(1/2*Pi*x)*exp(2*y(x)) = 0:
bcs := y(0) = 0,y(1) = 0:
newode := (1/10*(1-lambda)+1/100)*diff(y(x),x,x)
          +exp(y(x))*diff(y(x),x)
          -1/2*Pi*sin(1/2*Pi*x)*exp(2*y(x)) = 0:
infolevel[`dsolve/numeric/BVP`]:=2:
ds:=dsolve({newode,bcs},numeric,continuation=lambda):
dsolve/numeric/BVPSolve: solving BVP using trapezoid-richextrap method
dsolve/numeric/BVPSolve: using hardware floating point routines
dsolve/numeric/BVPCont: computing initial solution profile by continuation
dsolve/numeric/DeferredCorrect: correcting for order 2 error
dsolve/numeric/BVPSolve: got absolute error of 2.91951576497438481 with O(h^2) method
dsolve/numeric/BVPSolve: Computed required error to be 1.11651167704591 for an adjustment factor of 1.61705122459415
dsolve/numeric/BVPSolve: Increasing mesh from 32 to 52 points
dsolve/numeric/DeferredCorrect: correcting for order 2 error
dsolve/numeric/BVPSolve: ####Entering stage 3####
dsolve/numeric/BVPSolve: refining solution to desired accuracy using Richardson extrapolation
dsolve/numeric/RichardsonExtrap: Start Richardson extrapolation using mesh multiplication, original grid is 52 points
dsolve/numeric/RichardsonExtrap: correcting for order 2 error using a grid of 103 points
dsolve/numeric/RichardsonExtrap: correcting for order 4 error using a grid of 154 points
dsolve/numeric/RichardsonExtrap: correcting for order 6 error using a grid of 205 points
dsolve/numeric/RichardsonExtrap: correcting for order 8 error using a grid of 256 points
dsolve/numeric/RichardsonExtrap: correcting for order 10 error using a grid of 307 points
dsolve/numeric/BVPSolve: ####Entering stage 4####
dsolve/numeric/BVPSolve: Estimated error with interpolation to be 8.94901865584014e-005
dsolve/numeric/BVPSolve: Increasing mesh from 52 to 81 points
dsolve/numeric/BVPSolve: refining solution to desired accuracy using Richardson extrapolation
dsolve/numeric/RichardsonExtrap: Start Richardson extrapolation using mesh multiplication, original grid is 81 points
dsolve/numeric/RichardsonExtrap: correcting for order 2 error using a grid of 161 points
dsolve/numeric/RichardsonExtrap: correcting for order 4 error using a grid of 241 points
dsolve/numeric/RichardsonExtrap: correcting for order 6 error using a grid of 321 points
dsolve/numeric/RichardsonExtrap: correcting for order 8 error using a grid of 401 points
dsolve/numeric/RichardsonExtrap: correcting for order 10 error using a grid of 481 points
dsolve/numeric/BVPSolve: Estimated error with interpolation to be 4.6173768506504e-006
dsolve/numeric/BVPSolve: Increasing mesh from 81 to 98 points
dsolve/numeric/BVPSolve: refining solution to desired accuracy using Richardson extrapolation
dsolve/numeric/RichardsonExtrap: Start Richardson extrapolation using mesh multiplication, original grid is 98 points
dsolve/numeric/RichardsonExtrap: correcting for order 2 error using a grid of 195 points
dsolve/numeric/RichardsonExtrap: correcting for order 4 error using a grid of 292 points
dsolve/numeric/RichardsonExtrap: correcting for order 6 error using a grid of 389 points
dsolve/numeric/RichardsonExtrap: correcting for order 8 error using a grid of 486 points
dsolve/numeric/BVPSolve: Estimated error with interpolation to be 1.11619447896115e-006
dsolve/numeric/BVPSolve: Increasing mesh from 98 to 107 points
dsolve/numeric/BVPSolve: refining solution to desired accuracy using Richardson extrapolation
dsolve/numeric/RichardsonExtrap: Start Richardson extrapolation using mesh multiplication, original grid is 107 points
dsolve/numeric/RichardsonExtrap: correcting for order 2 error using a grid of 213 points
dsolve/numeric/RichardsonExtrap: correcting for order 4 error using a grid of 319 points
dsolve/numeric/RichardsonExtrap: correcting for order 6 error using a grid of 425 points
dsolve/numeric/RichardsonExtrap: correcting for order 8 error using a grid of 531 points
dsolve/numeric/BVPSolve: Estimated error with interpolation to be 5.61718208533154e-007

bvp_infolevel.mw

I get this in Maple 2018.2 and Maple 2020.0 (64bit Linux). This is a shorter and slightly different example.

restart;
kernelopts(version);
    Maple 2020.0, X86 64 LINUX, Mar 4 2020, Build ID 1455132

sum1 := Sum(1/((11-2*n)!*(n-1)!*(29+2*n)!),n=2..3):

value(sum1) ;
                              173                    
          -------------------------------------------
          7439866535798024349359988963016704000000000

simplify(sum1);
Error, (in evalr/evalr) too many levels of recursion

foo:=convert(sum1,GAMMA);
              3                                           
            -----                                         
             \                                            
              )                      1                    
     foo :=  /    ----------------------------------------
            ----- GAMMA(12 - 2 n) GAMMA(n) GAMMA(30 + 2 n)
            n = 2                                         

combine(foo);
                               0

simplify(foo);
                               0

value(foo);
                              173                    
          -------------------------------------------
          7439866535798024349359988963016704000000000

simplify(sum1);
                               0

I'll point out that simplify(sum1) returned 0 at the end, although earlier it produced a recursion limit error. On some runs combine(foo) would also error out like that, with foo in GAMMA form.

simplify_ex_ac.mw

And one more short example (without the (n-1)! in the denominator). simplify_exac2.mw

Someone might mention that add is a better choice for adding up a finite number of terms. But that seems a mere sidebar here. The following is also interesting, where the case that N<5 is pushed aside.

restart; sum(1/((11-2*n)!*(29+2*n)!),n=2..N,formal=true);

                             3079                     
         ---------------------------------------------
         130088533681106143868879347831013376000000000

restart; sum(1/((11-2*n)!*(29+2*n)!),n=2..N,formal=false);

  Error, (in SumTools:-DefiniteSum:-ClosedForm) summand is
  singular in the interval of summation

And,

restart;
combine(Sum(1/(GAMMA(7-2*n)*GAMMA(1+2*n)),n=2..3,formal=false));
                               0

restart;
combine(Sum(1/(GAMMA(7-2*n)*GAMMA(1+2*n)),n=2..3,formal=true));
                               0

It looks like your plan is to have the module local atable be assigned the actual table, rather than just a name that refers to that table. For example,

TestLibrary := module()
    export aset,atable:
    option package:

    aset := myset:
    atable := eval(mytable);
end module

If -- as you had it -- the module local is only assigned the name of the table (ie. mytable) then that's what gets stored in the archive.

This evaluation behavior is special to a few data structures, including table and Record -- but not list, set, Matrix/Vector/Array.

You might want to read the Help pages for table , in particular the 5th bullet point which describes that a table has special evaluation rules. See also last name evaluation .

Attached is a revision that preserves the table, upon savelib and restart.
TestLibrary_ac.mw