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

I now see that the problem is not because of how solve (or machinery underneath it) works, but how arccos works.

In my previous Comment's result from solve, the problematic arccos calls were not automically resolving until I used forget. That's still unfortunate. But I suspect that the following cause (of that issue) has broader implications.

restart;

kernelopts(version);

        Maple 2016.2, X86 64 LINUX, Jan 13 2017, Build ID 1194701

arccos(1/4*5^(1/2)-1/4); # good

                          2 Pi
                          ----
                           5

prob := arccos(1/4-1/4*5^(1/2)); # hmm

                                  1/2
                                 5
            prob := Pi - arccos(---- - 1/4)
                                 4

arccos(1/4*5^(1/2)-1/4); # hmm

                                  1/2
                                 5
                         arccos(---- - 1/4)
                                 4

forget(arccos);

prob;

                                3 Pi
                                ----
                                 5

arccos(1/4*5^(1/2)-1/4);

                                 2 Pi
                                 ----
                                  5

I can understand that Maple might prefer to pull out a negative sign from arccos(1/4-1/4*5^(1/2)) (and shift the result accordingly). But oughtn't it to be checking whether the new, resulting call like arccos(1/4*5^(1/2)-1/4) can produce a result before putting it, unevaluated, into the temporary Cache?

After calling forget(arccos), if I once again call arccos(1/4-1/4*5^(1/2)) then once again the unevaluated call arccos(1/4*5^(1/2)-1/4) will be put back into the temporary Cache of arccos. Unfortunate.

This kind of behaviour by arccos seems to go back to at least Maple 9. Parts of Maple prefer cos. Another effect, using Maple 2016.2,

restart;

ee:=identify(1.884955592):

ee;

                         1/2
                        5
           Pi - arccos(---- - 1/4)
                        4

forget(arccos);

ee;

                       3 Pi
                       ----
                         5

The relevant code seems to be the else clause of `arccos/normal`. It might be that uneval quotes prevent some infinite recursion, but I don't really see why it's needed for that subcase. If the sign is 0 then ok, and if the sign is -1 then calling actively on -x should recurse to the first clause (which is protected by uneval). Maybe I'm missing something. It is Friday, after all.

showstat(`arccos/normal`);

`arccos/normal` := proc(x)
   1   if `tools/sign`(x) = 1 then
   2     arccos(-x) := Pi-('arccos')(x);
   3     arccos(x) := ('arccos')(x)
       else
   4     arccos(-x) := ('arccos')(-x);
   5     arccos(x) := Pi-('arccos')(-x)
       end if
end proc

Regarding a comment in my previous example: the following call to solve (or something underneath that) is not cleaning up some assignments into the temporary Cache of the arccos procedure. I think that it ought to do such clean-up, without any sort of extra burdern on the user to do something like call forget.

This changed between Maple 12.02 and 13.00, I believe. SCR submitted.

Download arccos_cache.mw

@John Fredsted I would imagine that most people here know the values of cos at the multiples of Pi/4, but thanks for following up. And again thanks sincerely for your Answer.

Carl has now shown a systematic method for that "first step". I'm now trying to figure out why Maple resolves some similar examples...but not some/most.

restart;

# Why does it forget this is 2*Pi/5 later on!? Option cache?
id:=''arccos''(1/4*5^(1/2)-1/4)=arccos(1/4*5^(1/2)-1/4):

x1:=arcsin(convert(sin(7*Pi/20),radical)):

lprint(x1);
arcsin(-1/8*2^(1/2)+1/4*(5+5^(1/2))^(1/2)+1/8*2^(1/2)*5^(1/2))

p:= evala(Norm(z-convert(op(x1), RootOf))):
d:= degree(p):
p2:= combine(eval(p, z= invfunc[op(0,x1)](x))):
s:= subs(id,[solve(p2, allsolutions)]);

      s := [-3/10 _B1~ Pi + 1/2 Pi _Z1~ + 3/20 Pi,
            -1/10 _B1~ Pi + 1/20 Pi + 1/2 Pi _Z1~]

S1:= [seq(seq(eval(s[1], [_B1=kk,_Z1= k]), k= 0..d-1),kk=[0,1])]:
S2:= [seq(seq(eval(s[2], [_B1=kk,_Z1= k]), k= 0..d-1),kk=[0,1])]:
S:= [S1[],S2[]]:

S[min[index](abs~(x1 -~ S))];

                             7 Pi
                             ----
                              20

BTW, vv's arctan example above also worked for me, after preliminary conversion to arcsin.