@tomleslie First, just for clarity: I did not know that John May had suggested something like Digits=30, and happened to have found out Digits=50 was unnecessary yet Digits=20 was inadequate. I found through experimentation that Digits=30 was adequate for the given parameter set.

Tom, your explanation is mostly fine, as regards `sum` versus `add`. One important additional note on `sum` though: Using symbolic `sum` can sometimes be exceptionally inefficient *in the case where it tries hard symbolically to find a closed value yet fails before reverting to explicit summation of the finite number of terms.*  For the given code that slow, doomed failure is repeated (at great, wasted expense) all of the tens of thousands of times through the loops. So the most important gain is by avoiding highly duplicated, unsuccessful symbolic summation -- and instead forcing a scheme of finitely-termed numeric summation.

Also, you miss the key point about using `Sum` here, which ends up being quite faster than `add`.  Inert `Sum` is NOT just for programmatic manipulation or evaluating via `value` (which turns it into active `sum`). Wrapping `Sum` with `evalf` causes special purpose routine `evalf/Sum` to be invoked. That uses a so-called Levin transformation to detect convergence of the summation based on a finite number of terms, and exit earlier (ie. accelerated) yet accurately. That is all demonstrated in my Answer's attachment.

Using evalf(Sum(...)) is handily faster than using `add` when both are done with 70 as the upper index limit, and also when both are done with 100 as the upper index limit.

@kuwait1 Yes, I know quite well that there are numerical difficulties here when the working precision is not high enough (ie. the results "differ" as you say). I just wanted to find out the level in which I ought to couch explanation and details. I may not get the opportunity to look deep at the precise cause for a while.

@kuwait1 I can respond with details at several possible levels, but it would help to know your current level of understanding.

It might be that you are unfamiliar with basic  concepts of numerical (floating point) computation, and in particular numerical roundoff error. For this a web search or Wikipedia should suffice.

For this level you might also benefit from a proper explanation of the difference between the Maple commands: symbolic `sum` , explicit `add` for summing a finite number of terms, and inert `Sum` which here be used for accelerated floating-point summation. (It's a terrible shame that Maple's side palette contains `sum` which is often the wrong choice altogether.)

Or you may be familiar with those concepts in general but not with how they affect Maple. In particular I include Maple's behavior of striving for accuracy to within 0.6 ulps (based on the current Digits setting) on atomic operations (calls to elementary functions, arithmetic, etc) but NOT for compound operations. For compound expressions/operations small roundoff noise or small numeric error can be magnified by the outer operations. For this a close reading of key sections of Maple's Programming Manual might suffice.

Or you might be familiar with all the above, and want detailed surgical analysis of just where and how your computations get into which specific numerical difficulties.

@Axel Vogt Your worksheet contains a function call to b, rather than a multiplication. Ie,

b(-A*K(3,Pi/6)+B*K(6,Pi/6)

instead of,

b*(-A*K(3,Pi/6)+B*K(6,Pi/6)

evalf(eval(a*b, Params));

             0.295315640000000

@w-Teilchen You can enforce a view.

plots:-contourplot( 1/(x^2+y^2), x=-2 .. 2, y=-2 .. 2,
                    method="alternate",
                    contours=[seq(i,i=0.5..4,0.5)],
                    view=[-2..2, -2..2] );

(The plots:-implicitplot command has an option rangeasview which I imagine was originally intended as a convenience to avoid having to enter the ranges twice. That might make it relate to what I mentioned about my wanting to pass along options to the underlying implicitplot command.)

@vv The assuming facility does not place assumptions on variables present only within a procedure body (here, f).

That is documented in the current last example on the assuming help page.

@vv I was able to get similar results using just simplify and radnormal under the positive assumption.

I was able to squeeze it a little more, but not by much. I don't see a really nice factorization, offhand.

u:=f(3): u:=simplify(radnormal(u)) assuming positive:

lprint(u);
(A*L^4*c^2*dz^4*s^2+2*A*L^4*c*dz^4*s^3+A*L^4*dz^4*s^4+B*L^3*c^2*dz^3*s+2*B*L^3*c*dz^3*s^2+B*L^3*dz^3*s^3+3*A*L^2*a^2*c*dz^2
*s+3*A*L^2*a^2*dz^2*s^2+2*B*L*a^2*c*dz+2*B*L*a^2*dz*s+A*a^4)/a^4

u:=f(3): u:=simplify(simplify(radnormal(u)),size) assuming positive:

lprint(u);
(A*L^4*s^2*(s+c)^2*dz^4+B*L^3*s*(s+c)^2*dz^3+3*A*L^2*a^2*s*(s+c)*dz^2+2*B*L*a^2*(s+c)*dz+A*a^4)/a^4

U:=proc(e)
  local u;
  u:=simplify(simplify(radnormal(e)),size) assuming positive;
  thaw(collect(numer(subs(s+c=freeze(s+c),%)),freeze(s+c),
               ff->simplify(simplify(radnormal(ff)),size))
       /denom(subs(s+c=freeze(s+c),%)));
end proc:

u:=f(3): u:=simplify(simplify(radnormal(u)),size) assuming positive: u:=U(u):

lprint(u);
(L^3*dz^3*s*(A*L*dz*s+B)*(s+c)^2+L*a^2*dz*(3*A*L*dz*s+2*B)*(s+c)+A*a^4)/a^4

@Joe Riel I have a recollection that (since Maple 14 or so) the recognition of Help database files (within folders/directories that only get added to libname with an initialization file) is done when the Standard GUI gets a completely fresh re-launch. By that I mean that, in order to pick up augmented Help locations, all currently opened sheets/tabs must be closed and the GUI launched anew.

The kernel doesn't have that problem with recognizing .mla archives, but the GUI needs a relaunch to pick up added folders/directories.

If a .hdb or .help file is added to a location that was already within libname (at last launch) then it becomes available (on restart, say). So this issue seems to depend on the location itself being newly added to libname since last launch.

That's my recollection, at least.

@sand15athome 

FYI, here are a few examples of things whose functionality relies on those DocumentTools subpackages. Their help-pages may give more of an idea than do the help-pages of just the Layout and Components commands. You might have a glance at some of these commands' help-pages. Some of these commands produce "applications" with which one can subsequently interect, though of course the underlying facilities can also be used to produce merely static results.

- The Explore command
- The DocumentTools:-Tabulate command
- The summarize=embed option to the Hypothesis Testing in the Statistics package
  (see the hypothesis testing output in the help-page  ?updates/Maple2016/Statistics )
- The ImageTools:-Embed command
- The DataSets:-InsertSearchBox command

The DocumentTools:-InsertContent command allows you to "embed" the results into the current worksheet. The DocumentTools:-ContentToString command provides a step with which you can then (instead) save the results directly to a .mw file, or open it in a new GUI tab.

There is a bit more in the example worksheet available via the help-topic examples/ProgrammaticContentGeneration . Even if you do not want to build an involved interactive application you might still be interested in seeing how you can easily add simple controls which (post-insertion) reveal or hide key portions of generated GUI Tables.

@tomleslie I interpreted the OP's last paragraph as meaning that he did not want to presume knowledge of the result (A->C), nor use it (a priori I suppose) to verify implication.

@brian bovril vv's claim is not true. However not all global optimizers have the same overall quality, so DirectSearch is a good suggestion.

@vv The comment about Optimization being only a local solver is not true in the univariate  case (which this is).

@Joe Riel For such a univariate problem the option method=branchandbound will instruct the Optimization:-Maximize (or Minimize) command to try and find the global optimum.

Of course there is no numeric global optimization application (within or without Maple) that will find the global optimal for all tough examples, using default options. That is true of DirectSearch, univariate branchandbound in Optimization, Maple's newer GlobalOptimization with its 3rd party Optimus engine, Maple's older GlobalOptimization with Janis Pinter's LGO as 3rd party engine, or anything else in the world.

@John May 

restart;
kernelopts(version);

         Maple 18.02, X86 64 LINUX, Oct 20 2014, Build ID 991181

f := proc( M::Matrix(2,3) ) "hey"; end proc:

f( Matrix([[a,b,c],[d,e,f]]) );

                                  "hey"

f( Matrix([[a,b],[d,e]]) );

Error, invalid input: f expects its 1st argument, M, to be of type
 Matrix(2,3), but received Matrix(2, 2, [[...],[...]],datatype = anything)

@Joe Riel By supplying the option compact=false the IdentityMatrix constructor returns a Matrix without a restrictive indexing function. Eg,

M:=LinearAlgebra:-IdentityMatrix(5,compact=false);
M[3,2]:=U:
M;

The OP may also be interested to know that the default value of a Matrix entry is 0. So if constructing an identity Matrix by explicit looping then only one level of looping is needed (ie. to walk only the diagonal enties).