@Markiyan Hirnyk 

For better comparison, at least a restart should be issued before executing the second solve statement (this means also seting infolevel again). Otherwise, some steps are not executed again. Independent sessions may be better still, see the table at the end of ?restart > Description.

@Markiyan Hirnyk 

For better comparison, at least a restart should be issued before executing the second solve statement (this means also seting infolevel again). Otherwise, some steps are not executed again. Independent sessions may be better still, see the table at the end of ?restart > Description.

@acer 

Of course it could be done. As the code of Beta stands now, it depends largely for normalization, simplification and numeric values on the code of GAMMA. But I wonder whether it is wise or maintainable to keep multiple copies of the reflection formula (and so many other formulas) in different places of the library. As I see it, an acute problem with Maple is precisely the multiplicity of the implementation of the same or closely related functionalities. In this sense, I find that Edgardo's unification initiative for mathematical functions is a step forward. The actual problem, as I see it, is that this program is incomplete.

Another issue (an old issue) is what transformations should go automatic (automatic simplification and normalization) and which transformations should go by hand (calling simplify, etc). The situation is not satisfactory as there is no uniform implementation criteria for different mathematical functions because of "historical" reasons. This is also an area that needs improvements, though it is more difficult because of "code inertia". I understand that Edgardo also agrees on this evaluation, as he has expressed elsewhere.

And indeed, better reaction to assumptions and conditional answers are also needed, in my opinion. Note, in particular, that the simplification:

simplify(GAMMA(x)*GAMMA(1-x));
                                      Pi
                                   ---------
                                   sin(Pi x)

is actually wrong as the reflection formula is valid only for noninteger x (otherwise x needs not be restricted to real, or fractional in particular, see e.g. here). But a big problem to get assumption based transformations to work properly is that the is checker heuristics are too weak. See e.g.:

is(x,Not(integer)) assuming 0 < x, x < 1
                                      FAIL

Meaning that a real theorem checker needs to be incorporated into the system to make these proofs work.

What is mising in `simplify/GAMMA`? Apparently, the relationship Gamma trig (I guess the reflection formula ) is working for symbolic and nuneric arguments:

simplify(GAMMA(x)*GAMMA(1-x));
                                      Pi
                                   ---------
                                   sin(Pi x)

simplify(GAMMA(2/7)*GAMMA(5/7));
                                      Pi
                                   ---------
                                       2 Pi
                                   sin(----)
                                        7

So that Beta(x,1-x) could be transformed to sin right now:

(simplify@convert)(Beta(2/7,5/7),GAMMA);
                                      Pi
                                   ---------
                                       2 Pi
                                   sin(----)
                                        7

I think that the immediate problem here is that the normalization of Beta calls the builtin and library parts of GAMMA but nowhere `normal/GAMMA/global` (which implements the reflection formula) is being called, as it does in the call to simplify. On the other hand I agree that it is very important that the simplify family (and other families) were put in sync with the transformation nework of mathematical functions.

@Carl Love 

First of all I find that there is a bug in documentation. ?rsolve states that the calling sequence is rsolve(eqns,...) and "Parameters" state:

eqns - single equation or a set of equations

I do not find in "Description" any properly stated restriction on the form of the equation(s). Certainly all the examples show equations in polynomial form, but this is not a replacement for a correct description. The truth, for this kind of equations, is in the code (as usual):

showstat(`rsolve/firstord`,23..24);
`rsolve/firstord` := proc(R, inits, Fn)
local RR, init, A, B, C, D, F, Y, YY, n, solindex, y, solution, ckflag, i;
       ...
  23   RR := eval(RR,{y(n+1) = YY, y(n) = Y});
  24   if type(RR,('linear')(Y)) and type(RR,('linear')(YY)) and degree(RR,{Y, YY}) = 1 then
         ...
       elif type(RR,('linear')(Y)) and type(RR,('linear')(YY)) and degree(RR,{Y, YY}) = 2 then
         ...
       else
         ...
       end if;
       ...
end proc

More generally, I find that this is an organizational bug. Meaning not imposing uniform design criteria throughout the system and along the time. Additionally, I do not believe that rsolve is being actively maintained, while dsolve is (see Jacques's question).

@Carl Love 

First of all I find that there is a bug in documentation. ?rsolve states that the calling sequence is rsolve(eqns,...) and "Parameters" state:

eqns - single equation or a set of equations

I do not find in "Description" any properly stated restriction on the form of the equation(s). Certainly all the examples show equations in polynomial form, but this is not a replacement for a correct description. The truth, for this kind of equations, is in the code (as usual):

showstat(`rsolve/firstord`,23..24);
`rsolve/firstord` := proc(R, inits, Fn)
local RR, init, A, B, C, D, F, Y, YY, n, solindex, y, solution, ckflag, i;
       ...
  23   RR := eval(RR,{y(n+1) = YY, y(n) = Y});
  24   if type(RR,('linear')(Y)) and type(RR,('linear')(YY)) and degree(RR,{Y, YY}) = 1 then
         ...
       elif type(RR,('linear')(Y)) and type(RR,('linear')(YY)) and degree(RR,{Y, YY}) = 2 then
         ...
       else
         ...
       end if;
       ...
end proc

More generally, I find that this is an organizational bug. Meaning not imposing uniform design criteria throughout the system and along the time. Additionally, I do not believe that rsolve is being actively maintained, while dsolve is (see Jacques's question).

That escaped variable _O is a local of SumTools:-Tools:-MakeEquations:

kernelopts(opaquemodules=false):
showstat(SumTools:-Tools:-MakeEquations,5..7);
SumTools:-Tools:-MakeEquations := proc(expr, x)
local inds, t, z, _O, e;
       ...
   5   for z in inds do
   6     e := expand(subs(z = _O,expr));
   7     t := traperror(coeffs(e,_O));
         ...
       end do;
       ...
end proc

That escaped variable _O is a local of SumTools:-Tools:-MakeEquations:

kernelopts(opaquemodules=false):
showstat(SumTools:-Tools:-MakeEquations,5..7);
SumTools:-Tools:-MakeEquations := proc(expr, x)
local inds, t, z, _O, e;
       ...
   5   for z in inds do
   6     e := expand(subs(z = _O,expr));
   7     t := traperror(coeffs(e,_O));
         ...
       end do;
       ...
end proc

My former hope was that developments in parallelization would help. That is, with ten or more definite integration methods, it does not seem wise, as a systematic methodology, computing sequentially the results for all these methods, and then deciding which one to take (based on symbolic size, numeric value or whatever check). However, thread parallelization does not seem feasible in any foreseeable future (it would require massive parallelization of the whole library). And grid parallelization is probably not of help either as the overhead time may be excessive in most cases (actually, I wonder how to measure this overhead time).

So, it seems that sequential computing cannot be avoided at present. Yet, the current scheme has the additional "feature" of a fixed order for the list of definite integration methods. Well, fixed for a given release, this order has been changing along the Maple versions. My guess is that they run a bunch of integrals and test with different orders, so that the chosen order arises from some statistics on their sample. But this methodology has been used for many years and sounds to me too primitive: most probably it cannot deal well with integrals not significantly represented in that sample, or directly outside it. I believe that it should not be difficult to construct dynamically the list of integrator methods, based on some analysis of the pattern of the integral. For instance, method contour could be higher than ftoc for those integrals that it deals better and faster (e.g., probably, rational integrands on infinite or semi-infinite intervals, see this example). This is not something new. Actually, some other routines like simplify do similar things.

Certainly, it would be interesting to know how other CAS deal with this issue, and which is the state of the art in the theory.

@acer 

In the "end", the differences or complication with method cook can be traced to a peculiarity in the normalization of GAMMA:

trace(GAMMA):
Beta(2/5,3/5); 
Beta(2/7,5/7);

This problem of the first "successful" method producing a more complicated or wrong answer does occur too frequently, as posts here and elsewhere show. A better scheme is needed beyond sequentially trying methods. The probability of a user observing the output from the method _RETURNVERBOSE is negligible. So, the potential of the definite integration methods implemented in Maple is underused.

OK. It is again the issue of the first successful method in the row. For a=5/2 and a=7/2 the first successful method is cook:

infolevel[IntegrationTools]:=3:
int(1/(1+x^(5/2)), x=0..infinity); 

Definite Integration:   Integrating expression on x=0..infinity
Definite Integration:   Using the integrators [distribution, piecewise, series, o, polynomial, ln, lookup, cook, ratpoly, elliptic, elliptictrig, meijergspecial, improper, asymptotic, ftoc, ftocms, meijerg, contour]
LookUp Integrator:   unable to find the specified integral in the table
Cook LookUp Integrator:   returning answer from cook pattern 1a
Definite Integration:   Method cook succeeded.
Definite Integration:   Finished sucessfully.
                                        Pi
                                 2/5 ---------
                                         2 Pi
                                     sin(----)
                                          5

int(1/(1+x^(7/2)), x=0..infinity); 
Definite Integration:   Integrating expression on x=0..infinity
Definite Integration:   Using the integrators [distribution, piecewise, series, o, polynomial, ln, lookup, cook, ratpoly, elliptic, elliptictrig, meijergspecial, improper, asymptotic, ftoc, ftocms, meijerg, contour]
LookUp Integrator:   unable to find the specified integral in the table
Cook LookUp Integrator:   returning answer from cook pattern 1a
Definite Integration:   Method cook succeeded.
Definite Integration:   Finished sucessfully.
                               2/7 Beta(2/7, 5/7)

Most interesting as both results in terms of sin and Beta arise from the same pattern 1a. A workaround to get the answer in terms of sin is suppressing the method cook, so that the method meijergspecial gets its oportunity:

int(1/(1+x^(7/2)), x=0..infinity,method=nocook); 
                                           3 Pi
                                2/7 Pi sec(----)
                                            14
convert(%,sin);
                                        Pi
                                 2/7 ---------
                                         5 Pi
                                     sin(----)
                                          7

I get in Maple 15.01:

int(1/(1+x^a), x=0..infinity); #no assumption on a !
                                          Pi
                                  Pi csc(----)
                                          a
                                  ------------
                                       a

int(1/(1+x^(5/2)), x=0..infinity); 
                                        Pi
                                 2/5 ---------
                                         2 Pi
                                     sin(----)
                                          5

It is true. Consider this test code:

test:=module()
local testname,
ModuleApply:= proc(a)
thismodule:-testname:=a:
print(thismodule:-testname);
end proc:
end module:

test(q);

It produces an error in Maple 13.02:

test(q);
Error, (in ModuleApply) module does not export `testname`

while it works fine in Maple 14.01:

test(q);
                                       q

I am not aware that this change was ever documented.

It is true. Consider this test code:

test:=module()
local testname,
ModuleApply:= proc(a)
thismodule:-testname:=a:
print(thismodule:-testname);
end proc:
end module:

test(q);

It produces an error in Maple 13.02:

test(q);
Error, (in ModuleApply) module does not export `testname`

while it works fine in Maple 14.01:

test(q);
                                       q

I am not aware that this change was ever documented.

Interestingly, the intuitive calls convert(...,sin) and convert(...,cos) are not documented...E.g. see also here.