@pagan 

Thank you for this very interesting and useful information. Indeed, inspecting in detail the code of the definite integration sector is something yet in my queue.

I have to say though that the effect of not documenting commands or options so interestingl like these methods is generating the impression that Maple weaknesses are larger than real, and making this system less useful to the ordinary user than it could be.

Certainly, I have in mind parallelism a la Grid, at least for the near future.

@pagan 

Thank you for this very interesting and useful information. Indeed, inspecting in detail the code of the definite integration sector is something yet in my queue.

I have to say though that the effect of not documenting commands or options so interestingl like these methods is generating the impression that Maple weaknesses are larger than real, and making this system less useful to the ordinary user than it could be.

Certainly, I have in mind parallelism a la Grid, at least for the near future.

@Robert Israel 

Clearly, in case of discrepancy, a checking stage is necessary. One posibility is computing a numerical approximation. In cases like this example it would be enough to decide what result to return:

int(exp(-x)/(1-exp(-x)),x=0..infinity,numeric);
                           Float(infinity)

I think that this is an area that needs further investigation, as it would be relevant to integrals, sums, differential equations, etc.

@Robert Israel 

Clearly, in case of discrepancy, a checking stage is necessary. One posibility is computing a numerical approximation. In cases like this example it would be enough to decide what result to return:

int(exp(-x)/(1-exp(-x)),x=0..infinity,numeric);
                           Float(infinity)

I think that this is an area that needs further investigation, as it would be relevant to integrals, sums, differential equations, etc.

In the case of the interval 0..1, the method that succeeds is ftoc:

int(exp(-x)/(1-exp(-x)),x=0..1,method=ftoc);
                            infinity

Not surprisingly, it also succeeds on the whole interval:

int(exp(-x)/(1-exp(-x)),x=0..infinity,method=ftoc);
                            infinity

The main problem illustrated by this example is that as integration methods are tried in sequence. Then, if an earlier one claims success, by default it will be the one giving the answer, even when producing a wrong result. And even while methods laying later in the queue might have succeeded and found the right answer in case they were given the chance. This scheme looks to me a bit primitive. My guess is that a better approach would be giving all the implemented methods an opportunity by running them in parallel.

In the case of the interval 0..1, the method that succeeds is ftoc:

int(exp(-x)/(1-exp(-x)),x=0..1,method=ftoc);
                            infinity

Not surprisingly, it also succeeds on the whole interval:

int(exp(-x)/(1-exp(-x)),x=0..infinity,method=ftoc);
                            infinity

The main problem illustrated by this example is that as integration methods are tried in sequence. Then, if an earlier one claims success, by default it will be the one giving the answer, even when producing a wrong result. And even while methods laying later in the queue might have succeeded and found the right answer in case they were given the chance. This scheme looks to me a bit primitive. My guess is that a better approach would be giving all the implemented methods an opportunity by running them in parallel.

@Preben Alsholm 

This problem arises in method cook:

infolevel[IntegrationTools]:=3:
int(exp(-x)/(1-exp(-x)),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]
IntegralTransform LookUp Integrator:   Integral might be a laplace transform 
with expr=1/(1-exp(-x)) and s=1.
IntegralTransform LookUp Integrator:   Integral transform returned unevaluated.
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.
                             gamma

Hence, a workaround is avoiding it:

restart:
int(exp(-x)/(1-exp(-x)),x=0..infinity,method=nocook);
                            infinity

Or directly using the method that finds the answer:

int(exp(-x)/(1-exp(-x)),x=0..infinity,method=asymptotic);
                            infinity

The following threads are somewhat related to your question:

rule based integration

Webinar on Symbolic Integration

@Alec Mihailovs 

I agree. Also, probably, there is no command readily available that computes multivariable asymptotic expansions like here "for x and y with large absolute values". Then, a clumsy workaround like the following is needed:

ex:=16*x^4-y^4-y^3-3*x^2+y+1:
MultiSeries:-series(subs(y=a*x,ex),x=infinity,1):
algsubs(a*x=y,expand(%)):
[allvalues(RootOf(%,y))]:
(simplify@asympt)~(%,x,2);

        [2 x + O(1), 2 I x + O(1), -2 x + O(1), -2 I x + O(1)]

Additionally, this routine `series/RootOf` is a kind of bottleneck as MultiSeries routines also use it. So, it seems that it will provide material for many reports...

@Alec Mihailovs 

I agree. Also, probably, there is no command readily available that computes multivariable asymptotic expansions like here "for x and y with large absolute values". Then, a clumsy workaround like the following is needed:

ex:=16*x^4-y^4-y^3-3*x^2+y+1:
MultiSeries:-series(subs(y=a*x,ex),x=infinity,1):
algsubs(a*x=y,expand(%)):
[allvalues(RootOf(%,y))]:
(simplify@asympt)~(%,x,2);

        [2 x + O(1), 2 I x + O(1), -2 x + O(1), -2 I x + O(1)]

Additionally, this routine `series/RootOf` is a kind of bottleneck as MultiSeries routines also use it. So, it seems that it will provide material for many reports...

@pagan 

Have you reported these bugs?

My feeling is that an error like this one, when patching/updating a routine written years before, is more likely to occur because the source code logic was not properly documented (in the sense of literate programming).

@pagan 

Have you reported these bugs?

My feeling is that an error like this one, when patching/updating a routine written years before, is more likely to occur because the source code logic was not properly documented (in the sense of literate programming).

@Art Kalb 

Reasons are described in ?extension. My guess is that extensions/improvements are planned for future releases, and they will better implemented using the "Modern Extension Mechanism". E.g. int has changed from procedure to module in Maple 13, and the code of its frontend sector has been improved in module fashion, see ?updates,Maple13,symbolic.

@Christopher2222 

Find it here (fortunately an external archive is maintained...).

@pagan 

Both bugs are regressions starting from Maple 10.

In Maple 9.52:

asympt(RootOf(16*x^4-y^4-y^3-3*x^2+y+1,y),x,2);
                                   3        1
                     -2 x - 1/4 + ---- + O(----)
                                  64 x       2
                                            x

About understanding the mix of try..catch and lasterror, proper documentation would have helped. The code in M9.52 uses traperror and lasterror statements. It sounds like a traperror statement was replaced with a try..catch construct.

Another difference that I find remarkable is that the current solve statement in line 40 uses the option Explicit, producing a large complex expression, which may be harder to handle.

On the other hand, it seems that the Standard GUI's prettyprinting bug (at levels 2 or 3) affects names, while function calls print OK:

proc() try catch: f; end try; end proc;
                                 proc () try  catch:  end try end proc

proc() try catch: f(); end try; end proc;
                                 proc () try  catch: f() end try end proc

No such problem occurs in Maple 9.52 Standard GUI.