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

@Carl Love Thanks, Carl. Those initial lines of your code, to compute p2, are impressive.

@John Fredsted No worries. My version involved convert(cos(16*x1),expln) and I ought to have noticed that is exactly 0. It would be more apparent if I'd just done expand(cos(16*x1)) instead. Then it would be even more like member vv's expand(cos(16*x1)) which also produces 0 immediately. (I had to edit my previous comment too, to apologized for the close but unintentional duplication of approach.)

And your first observation can be had directly, as expand(cos(8*x1)) which returns sqrt(2)/2. So that too is in the same camp: noticing that cos(N*x1) equals something with known useful properties (for the trig inversion).

To me these "fortuitous" first steps are even more ad hoc as finding the values of the introduced parameter in the latter step.

@Markiyan Hirnyk Thank you, that sets the bar higher.