@Kitonum 

The antiderivative is computed correctly, but it is not continuous, which techically is not a bug:

restart;
F:=int(sqrt(1+((k*Pi)/l*cos((Pi*x)/l))^2), x) assuming k>0,l>0:
F22:=eval(F,[l = 2, k = 2]):
limit(F22,x=2,left) - limit(F22,x=0, right); 
evalf(%);

      4*EllipticE(Pi*I)/Pi
      4.609785320 - 0.*I

@mehdi jafari 

I tried DirectSearch instead of fsolve.
It seems that the system has no solutions, see the attached worksheet.

Inflation-Inverse-1-vv.mw

@mehdi jafari 

Your code is not usable. You have merged procedures and expressions: e.g. if F and G are procedures with parameter x, F(x) + G(x) makes sense but F + G(x) or F + x^2  are usually nonsenses.

In your first post, eq2 contains  int( T[rr]*r, r=s..t)
but T[rr]  does not depend on r (r appears as an integration variable).

So, before turning Eq1,...,Eq4 into procedures, you must clarify the equations mathematically.
Note that if you are going to have double integrals (which is not clear for now), fsolve will probably be inacceptably slow or even fail.

@Kitonum 

I think the OP wants to insert rational numbers with minimal denominators between the elements of a sorted  list(realcons).
I don'd know why he does not try to state the question more clearly.

@acer 

Strange indeed. A "normal" answer should have been

X:= n -> piecewise(n<10, [1,22,-308,-3003,21021,105105,-360360,-765765, 765765][n], 0);

obtained easily using rsolve({req, x(1)=1}, x, makeproc);

How did you think at assuming integer? Vote-up for this!

@Carl Love 

A "Godelian" example would look quite different. This one should be easy for a human but difficult for Maple. BTW, the answer is "true".

A tough test for Maple would be:

F := piecewise(exp(x+exp(x)-sin(x^2))>=x+1-cosh(x/2), 2*x+1, x^2);

@Kitonum 

You are right. I was fooled by Maple's solve. I am disappointed that Maple fails for a simple rational polynomial system:

sys := [x^2 + y^2 - x*y - 1 = 0, y^2 + z^2 - y*z - a^2 = 0, z^2 + x^2 - x*z - b^2 = 0]:
ab:={a=10,b=104/10}:
solve(eval(sys,ab), allsolutions):
evalf[20]([%]);

    [{x = 1.1419533726022634876, y = 0.42279817537010308072, z = -9.7818952278636396166}]

The option size for 3D plots (implemented via ROOT) does not work as expected (unlike the 2D case). Here the plot is cropped sometimes; the PLOT3D driver is probably not yet ready for this option.
But of course it's nice to have it now, even if we must play with the size parameters in order to obtain an acceptable plot.
Examples:

Compare:
plot3d(x^2+y^2, x=-2..3,y=-2..3);
plot3d(x^2+y^2, x=-2..3,y=-2..3, scaling=constrained);

with

plot3d(x^2+y^2, x=-2..3,y=-2..3, size=[400,800]);

plot3d(x^2+y^2, x=-2..3,y=-2..3, scaling=constrained, size=[400,800]);

plot3d(x^2+y^2, x=-2..3,y=-2..3, scaling=constrained, size=[300,1800]);

@amrramadaneg 

I don't know what you have computed in Mathematica, but:

1. U1(y,z)  does not depend on y.
2. U1 exists only vor small z. For example, for z=0.5, the integral does not exist.
plot(U(x,0.5), x=0..1, view=-5..5);

This is a mathematical fact, not related to any CAS.

@amrramadaneg 

Your plot does NOT make sense because int without an interval as parameter will introduce arbitrary constants.
Kitonum changed this by taking definite integrals using the intervals 0.1 .. X,  0.1 .. Y.
Actually 0.1  is not necessary because x=0 is a removable singularity.
The problem is the next singularity at x = x0 = 0.42...  For x>=x0  the integral does not exist, so your x = 0..10 (in plot) is nonsense too. The computations takes long because Maple tries to compute a lot of divergent integrals.

@Kitonum It does not answer the question.
For m=0 the problem is trivial. We have m=1.

restart;
S:=msolve(x^3+y^2 = 123, 124):
S[rand(1..nops([S]))()];
                        {x = 83, y = 72}
eval(x+y, %);
                              155

@Stretto 

Now, that you know the syntax, you have options.
For example, in Maple 2019:

(for i from 1 to 3 do    
    A := i:
    B := 10*i;
end);

        10, 20, 30

Or, you may redirect the output into a file and then filter its content.

@Carl. I was intrigued by the results obtained by your procedure and I have looked closer to the u[i] inequalities.
The conclusion is that they are ok not only for n, but also for any n'>=n. So, your LPSolve call is correct and should produce the solution. Congratulations for your intuition and vote-up!
Unfortunately, LPSolve does not obtain the global minimum. I have checked with my brute-force procedure; it gives a better solution but this solution satisfies the LPSolve conditions, so it should have been found!