@baharm31 

Yes, you have found one continuous solution. implicitplot suggests that other solutions exists. They can be obtained by combining distinct branches of the RootOf. You might want to plot all the branches (after giving values to parameters) and inspect the intersection points; a rather tedious task because the RootOfs will depend on x.

Note that your equation can be reduced to a polynomial one, so that the Lagrange expansion applies, see
https://en.wikipedia.org/wiki/Lagrange_inversion_theorem

but this gives only local solutions.

You use here the term "solution" for what in mathematics is called "continuous selections" for a set-valued function
x |--> {y : f(x,y)=0}; this also appear in implicit function theorems.

solve is not designed for such tasks. It finds (in principle) the set {y : f(x,y)=0} and it is on your side to "assemble" the selections. Note that this could be a difficult task and the number of selections could be infinite.

On the other side, implicitplot simply plots the set of points {(x,y) : f(x,y)=0} and it is your eye which detects the selections. This plot could then be used to effectively assemble some solutions (if they actually exist, because the plot could be misleading).

Edit. Example:

How many continuous solutions y = y(x) do you detect for (y - sin(x))*(y - cos(x)) = 0, 0 <= x <= 4*Pi ?
(I am sure that you will miss some of them.)

I just suggested that if you want eigenvectors than it is better to use Eigenvectors instead of solving the characteristic polynomial. This is the case with your 1.mw.

Your coefficiens are in the range 10^(-25) .. 10^36 (approx). The degree of the polynomial is 50.
This will produce huge roundoff errors.
As acer said, Digits must be increased, but only if you are sure that the initial coefficients are very accurate [their precission should be also increased].
Otherwise the result will be useless.
Usually in such cases the function must be pre-processed and normalized; and an error estimate is recommended.

@Markiyan Hirnyk 

Thank you (in the name of the OP) for this valuable info :-)

Probably theta, phi, psi cannot be retrived easily. But you could insert your own sliders for theta, phi, psi and rotate the plot using them (via orientation=...). This way you will know their values.

@mahmood180 

F:=(m,t) -> piecewise(m=0,1,m<=r,cos(m*t),m<=2*r,sin((m-r)*t));
b:=(n,m,t) -> piecewise(n-1<=N*t and N*t<n,F(m,2*Pi*N*t),0);

Yes, you are right. I have recommended to plot the hyperbola, but I did not :-)

Edit.

Actually, the corect solve call for this case would be:

solve(sys, useassumptions) assuming x*y+2*x+4*y+6<0;

and now the result is NULL.

@Markiyan Hirnyk 

You can't ask Maple such proofs. But it is a high-school problem!

P.S. Can you prove using Maple for example that if a number is a multiple of 9 then the sum of its digits is also a multiple of 9?

@Markiyan Hirnyk 

1. The post was not edited at all.

2. You are right here but it is not difficult to see that for any n, h(n) = h(k) for some k<100.

@Markiyan Hirnyk 

Did you read the second version?

Here is the Maple version of a the solution solution presented in the book.
It is a "one-liner"!

h:= n -> h(`+`(op(`^`~(convert(n,base,10),2)))): h(1):=1: h(4):=4;

So, the happy ages are:

select(t->h(t)=1, [$1..100]);
   [1, 7, 10, 13, 19, 23, 28, 31, 32, 44, 49, 68, 70, 79, 82, 86, 91, 94, 97, 100]

The reason why the recursive h works (and does not generate an "infinite recursion" message)
is because it can be proved that the only values h takes are 1, 2 and 4 (this is not mentioned
in the book, but see the wiki article also mentioned in Rouben Rostamian's worksheet), and f(2) =4.

A simple solution is possible in Maple even if this fact is not used/known.
It is obvious that the iterates f(n), f(f(n)), ... repeat. The next version of h
also computes this sequence if it is invoked with a 2nd argument.

h:=proc(n, dummy:=NULL)
local S:=NULL, a:=`+`(op(`^`~(convert(n,base,10),2)));
while not(a in {S}) do
  S := S,a;
  a:= `+`(op(`^`~(convert(a,base,10),2)))
od;
if dummy=NULL then min(S) else S fi
end;


This version can be used to verify that h(N) = {1,2,4}.

`union`( seq({h(n)},n=1..100) );
   {1,2,4}

@Annonymouse 

As I understand your system is polynomial (or ca be reduced to such).
Solving a system of polynomial equations seems to be an easy task but it is not. The most powerful tool is Groebner bases (in the packages Groebner and PolynomialTools).
If Groebner bases are used, the answer if Eq[n+1] is "dependant" of the previous ones could be easy.

The problem is that the complexity for Groebner bases could be huge, and this depends heavily on the form of the polynomials.
So, without testing is is impossible to tell if such a tool can be used.

Here I supposed that you want a symbolic approach. For a numeric solution, you could try/experiment with fsolve and DirectSearch.

@Markiyan Hirnyk 

My last post in this thread
(I declare the question solved).


c:=1:
p:=x->a*x^11+b*x^4+c: q:=x->b*x^11+c*x^4+a: r:=x->c*x^11+a*x^4+b:
# s:=solve([p(x),q(x),p(y),r(y)]):
ss:=solve([p(x),q(x),p(y),r(y),p(z),r(z)]):
nops([ss]);

==> 41

But ss is not what you have said in words. You mean:
sss:=solve([p(x),q(x),p(y),r(y),q(z),r(z)]):

Now, this (inutile as I have mentioned) system seems to reach Maple's patience too
and I had to interrupt it after several minutes.
You may try to wait and see if it ends successfully (as it should).

PS. Unfortunately nobody else entered for this question. It would have been interesting to see other opinions.

That's all.

@Markiyan Hirnyk 

Oh my god, it seems that you are incorrigible! So, any dialog with you is very difficult and exhausting!

Have you tested the system? Of course it is compatible. Practically it's the same: I have said (it's easy to see) that for this system if (p,q) and (p,r) have common roots then (q,r) also has!