If you replace the upper limit for the index of the outer summation by 20 instead of 100 then for the given examples you can halve the time and only lose a few digits of accuracy.

However you may not be confident that doing so is always safe, with regards to accuracy loss. In that case you might well choose to go with i=0..infinity instead, leaving it to `evalf/Sum` to figure out how many terms to utilize.

See also my last Comment in my Answer to a previous, related Question of yours. (I got your computation time down there by about a factor of ten, if I recall...) I note that you never responded to this, "I don't understand why you are still [...] using Digits=50 and nterms=100, when you haven't shown examples of n and phi that require that much computational expense".

[edited] If I recall your original attempt in that earlier Question also used active sum, and that the performance improvement of instead using add or evalf(Sum(...)) in the simplest way was very large. Essentially it made near intractable example(s) run in much more reasonable time. And something like a "factor of ten" was only how much I was able to improve further upon that large benefit. And that basic improvement of replacing active sum didn't necessarily require changing the Digits or number-of-terms choices. So it seems remarkably odd that in this current Question you are still trying to use sum.

@Christopher2222 Nasser's methodology in those test suites has nothing to do with his adeptness  (or rather, he tries hard to ensure that).

That's on principle. He's assessing how well the products do using just their integration commands called on the original input.

It's already well known that many of the more problematic integrals can be done if a human assists the Computer Algebra System -- integrating by parts, change of variables, splitting the range, changing the representation, doing it by contour, etc etc.

Something similar can be said about the "size" of the results. Maple doesn't automatically simplify after several kind of computation, and for some Mathematica does. That also affects the timings -- Maple beats all the other systems hands down on speed in these integration test suites, but its mean result-size is huge.

Of course there are also some much shorter results that can attain because a pattern lookup formula exists and may be known to the system. (Think of factored polynomials in the denominator, for example.)

@Sternkopf I'll send you an email later this morning.

@wswain 

Yes, the `print/pre` procedure only affects the printing of a call like pre(expression), which otherwise remains unevaluated. It's not common to have to construct this kind of approach.

The following is a so-called anonymous procedure. I don't have to assign it to a name (e.g.. f) in order to be able to use it.

x->x^2

Here is another.

(a,b)-> a^2+b^2

Here's another.

(a,b)-> g(a) <= g(b)

Given some other proc g which returns a numeric value, that last anonymous proc can be used as a comparator. It can be used, say, as the additional optional argument passed to the sort command.

A procedure like,

proc(a,b) a^2+b^2; end proc

or,

(a,b) -> a^2+b^2;

is an entity unto itself. There are situations in which it can be used without having to first assign it to a name.

By itself, the definition of an anonymous procedure does not "do anything" to its formal parameter(s). For example the following does not affect the name X.

X -> X^2;

In 2D Input mode the GUI will allow you to optional interpret the following in the same way.

f(x) := x^2

f := x -> x^2

I consider allowing the former to be a very poor design choice, because it re-uses a syntax that already meant something else in the Maple language. Ambiguous language syntax and nomenclature ALWAYS leads to problems and user confusion.

Similarly for so-called "programmer indexing", which has nothing to do with this discussion (despite the connotations about procedures inherent in the term "programmer"). It involves using round brackets for indexing into Arrays/Vectors/Matrices, as an twist on the more usual square-bracket indexing notation. Round brackets after a name already meant function call (since forever), so highjacking it to also mean Array indexing was another  (somewhat recent) poor language design choice (and your confusion above is understandable).

@wswain There is no procedure defined and assigned to the name pre. That is key. So when you call pre(expression) the output is the same thing -- a so-called unevaluated function call.

Maple allows you to set up a custom printing procedure that will get used to prettyprint such an unevaluated function call. For such an unevaluated function call to pre, the print-extension procedure must be named `print/pre`.

So I constructed a `print/pre` printing extension procedure. What it does is build up another expression that displays the way you want. See section 10.3 of the Programming Guide for a brief subsection on this.

Maple uses an internal mechanism sometimes called uniquification or simplification (not to be confused with the simplify command). The Maple kernel (engine) maintains a simplification table of uniquifications of expressions. This helps in memory management, and aids efficiency. For example there is only ever one instance in memory of an expression such as x+y. If you later on type in y+x then the internal structure for that (DAG) is the very same one for x+y. Whichever order is the first to be created and store is the one to which the other will be uniquified. See the Appendix of the Programming Guide for a brief section on this.

The Maple command sort does allow for some behind-the-scenes in-place replacement. For example,

restart;

ee := w+v+x+y+z;

             ee := w + v + x + y + z

ee;

                w + v + x + y + z

op(1,ee), op(2,ee);

                      w, v

z+y+x+v+w;

                w + v + x + y + z

sort(ee, order=plex(y,z,x,w,v));

                y + z + x + w + v

ee;

                y + z + x + w + v

op(1,ee), op(2,ee);

                      y, z

z+y+x+v+w;

                y + z + x + w + v

Notice how the op command pulls out the operands (summands) in the order in which they are stored, and here that matches the order in which they appear in the pretty-printed display.

Now, the LHS of your equation is not a polynomial in the differential terms -- they are not names. The above kind of forced sort did not get me what you were after.

I can pick of the summands (operands) of the LHS of your equation. I can put them in a list. But if I then try and add them together (using commands add, or `+`, say) then I just get back something which gets uniqified back to the already-stored expression with the original ordering.

There are other ways approach this problem, and to mimic a re-ordered display. Some of those will introduce visible artefacts, such as extra brackets or single-quotes in the display, or italic instead of upright fonts, or partially gray rather than black forground. etc. I wanted to obtain something that would look as close as possible to the usual pretty-printed output, but with a forced order.

In the case that the interface(typesetting) level is standard, my custom print extension `print/pre` constructs another version of its argument expression in which the global name diff is replaced by a freshly generated local name diff. This new sum of terms will not have been created before, and shouldn't uniquify to some earlier ordering. In the case that the typesetting level is extended I used a weaker approach, which should work as long as you haven't utilized %diff and its other inert friends on the same expression (yet not ordered)  earlier. If you encounter a problem in that (more rare) scenario I can likely strengthen it.

I wrote this in the very early morning. At some point, in some variant of diff/Diff/D or typesetting level I believe I saw an expression where the internal ordering of the terms in the SUM DAG did not match the order of the prettyprinted terms. I actually gave up on a few other approaches because of that (and because of additional visible artefacts).

I hope that I did not miss some much easier solution which would cover all the cases.

@wswain I assumed you were just using shorthand in your Question, but I wrote my Answer to handle the actual kinds of expressions you would have in Maple.

If you try it out and find it lacking then please feel free to upload a problematic worksheet, and I can try to adjust.

You can rename the procedure `pre` to whatever you prefer, for terseness. You can also put its definition in the Startup Region of your document, to hide it out of sight.

@Christopher2222 So how about a DFT/GET approach?

> kernelopts(version);

     Maple 2017.0, X86 64 LINUX, May 17 2017, Build ID 1231047

> L:=sum( 1/ln(k), k=2..n ) * ln(n)/n:

> limit(L, n=infinity):

> lprint(%);
limit(sum(1/ln(k),k = 2 .. n)*ln(n)/n,n = infinity)

@markweitzman How about either,

Ctrl ?

or,

Shift \

on OS X.

See Help topic,

   worksheet/reference/hotmac

@markweitzman If you select the Phi or LerchPhi in the 2-D Output, and hit the F2 key, then does the appropriate Help page not open for you?

For fun, allowing for bold. And showing that it works alongside the usual captionfont option to control font family and font size.

colored_caption_2.mw

It should also be possible to adjust this to allow (separate) fine control over the font size of the various chunks. I didn't do that here.

It's a little disappointing that after so many years the data structures using for typesetting are still not documented. 

Here is a link to an older Answer about using specially constructed colored captions as legends for 3-D plots

You haven't given n a value.

It might be easier to help if you uploaded the whole worksheet.

What is the value of k ?

@tomleslie Those values may be a minimum, but it shows them as not being a solution.

It is a serious shortcoming of DirectSearch:-SolveEquations, that it leaves it up to the user to programmatically notice/test whether the returned values do in fact solve the equations, or (more critically) are close to an actual solution. For people who just want a small/smallest residual it's fine. But for people who need to know whether an actual solution exists the behavior is extremely poor.

@Carl Love The _S000002 is a temporary name that (I believe) solve or SolveTools creates, as a way of encapsulating properties (or assumptions) on names or subexpressions.