@_Maxim_ 

Tracing quickly the original code shows that `DEtools/formal_sol`  also has a remember mechanism
so probably a deeper analysis is needed. I do not envy those who are going to debug this.

@Carl Love 

The problem was about using GF(p,n), without defining it ad-hoc as a quotient ring. Using Domains should be (theoretically) faster. Of course, if p, n and the polynomials are small then this simpler method is preferable.

@Parham2016 

You have Int(...,  r=0..1);

@digerdiga 

It does not redefine the variable.
See  ?MathematicalFunctions,Assume

@Jasagredo 

Ok, you want to start from scratch and not take advantage of the code already existing in Domains.
I admit that the documentation for Domains is less than minimal, and the user is adviced to "study the code of existing domains", but then you are on your own.

@_Maxim_ 

In my answer (after edit) it also works if expressions are used instead of functions.
It would be interesting to investigate the source of the bug.

Added later.
The RootOf obtained by solve is a bit simpler.
For the OP's RootOf, Maple enters somehow in an infinite loop of simplifications/conversions.

@Axel Vogt 

Yes, the picture is the geometric interpretation.

I am a mathematician, not a physicist and I do not use the Physics package (except a few commands, very seldom).
I'd like to ask a few principial questions.
The Physics package looks to me like a "state within a state" with those Setups, redefined basic commands and operators (including *, .), special typesetting etc.
So, the questions.
- Is Maple going to evolve in these directions?
- Why in Maple is missing an AbstractLinearAlgebra or a Rings package (similar to the GroupTheory package)? Many of their commands could be used by Physics and would have a larger audience.
- Are the basic commands in Physics (such as Assume) going to be merged/unified with the existing ones (assume in this case)?

@Cryme 

The procedure uses the general solution obtained by solve (actually SemiAlgebraic).
E.g.
if the solution is  a<x<b, c<y<d then ==>  x = (a+b)/2, y = (c+d)/2
if the solution is  a<x, c<y<x then ==>  x = a+1, y = (c+a+1)/2
etc.

@jnjn0291 

Yes, provided that the eigenvalues are real. Otherwise take the real (or imaginary or both) parts. E.g.

plot3d([seq(Re(R(i)),i=7..8)], x=0..2*Pi,y=0..2*Pi);

@Markiyan Hirnyk 
Just use:
printlevel:=40;  # typesetting=standard

@Carl Love 

The user has m(R+x) (missing `*`). The main problem is using c[1],...,c[4]  and c  followed by  c := ...

@tsunamiBTP 
Yes.
If you just want sinc ant not the DynamicSystems package then define e.g.

sinc := x -> piecewise(x=0, 1, sin(x)/x);

@_Maxim_ 

I totally agree that an epsilon parameter would be nice, but not essential. Note that the epsilon in evalf/Int was also absent in the past. The main problem is the lack of methods.

BTW, the eulermac implementation is far from perfect, see here.

@_Maxim_ 

I don't think that such options are really necessary. Why use an epsilon when Digits should be enough? evalf/Sum usually increases internally Digits.

In your example Maple probably does not have a suitable convergence accelerator.
[The acceleration is usually more efficient for alternating series].

In such cases I think that a combination of symbolic+numeric methods should be used; of course here the symbolic one is sufficient, but take e.g.
evalf(Sum((1-10^(-3))^k/(k+ln(k)), k = 1 .. infinity));

The number of beginning terms is also superfluous because one may use
add(f(n),n=1..N) + Sum(f(n),n=N+1..infinity).