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.

@John Fredsted That's an interesting idea, although there is still the matter of determining the values of the introduced parameter (for you n=2 and -1 for the boolean, and for me below _Z1=7). And the choice of application by `cos`, and the choice of the scalar multiple, is also to be considered. But thanks for the idea. Here's another way to utilize it.

[edited] After I did the following implementation I reread the whole thread and realized that the code below is the essentially the same kind of approach as member vv's Answer. That duplication was completely unintentional, and my apologies to vv!

restart;

x1 := arcsin(1/2*(2+(2+(2+2^(1/2))^(1/2))^(1/2))^(1/2)):

K:=simplify(solve(cos(16*T)
                  =radnormal(convert(cos(16*x1),expln)),
                  allsolutions));

                  K := 1/32 Pi + 1/16 Pi _Z1~

v:=indets(K,name) minus {constants};

                         v := {_Z1~}

eval(K,v[1]=7);

                            15 Pi
                            -----
                             32

@vv That's the kind of thing I've been wondering. It would be sad if one had to resort to ever more nestings like `expand(combine(...))`.

On the one hand it seems Maple has difficulty simplifying mixed functional domains (e.g. arctrig and complex radicals). 

It may be that part of the difficulty is that `expand` and friends are hitting everything. Perhaps they could be used more selectively (e.g. frontend'ed).

I've see `solve` spit out arctan of complex radicals, quite often when given trig equations that I believe could be better handled by more examination of the periods of the individual trig calls contained.

@tomleslie Thanks, though I was trying to avoid `identify`, with the wording, "exact, symbolic steps".

@vv Thanks for looking, but as you've likely surmised I'm really after some kind of systematic approach where the target is as yet unknown.