@acer 

I think that the required functionality, discussion of the solution cases in terms of the parameters, is already available by `solve/parametric`, as Markiyan has suggested:

solve({eq1, eq2}, d, parametric=full);
{
{ [{d =
       2                    2        2          2      2                    2
    2 a  b - a - c - b + 2 b  a + 2 a  c + 2 a c  + 2 b  c + 4 a c b + 2 b c }]
               2      2                  2    2      2        2
    , - s/2 + a  b + a  c + 2 a c b + a c  + b  a + b  c + b c  = 0
                  2      2                  2    2      2        2
    [] , - s/2 + a  b + a  c + 2 a c b + a c  + b  a + b  c + b c  <> 0

About, looking into what different commands or call forms do, I think that the starting point here would be looking at infolevel messages, like:

infolevel[solve]:=3:

solve({eq1,eq2},d);
Main:   Entering solver with 2 equations in 1 variable
Linear:   solving 2 linear equations
Polynomial:   # of equations is:   2
Transformer:   system has a inconsistent linear subsystem
Main:   solving successful - now forming solutions
Main:   Exiting solver returning 0 solutions
solve:   Warning: no solutions found

eliminate({eq1,eq2},d);
Main:   Entering solver with 1 equation in 1 variable
Main:   solving successful - now forming solutions
Main:   Exiting solver returning 1 solution
[{d = s - a - b - c},
             2        2                    2      2        2          2
    {-s + 2 a  b + 2 a  c + 4 a c b + 2 a c  + 2 b  a + 2 b  c + 2 b c }]

solve({eq1, eq2}, d, parametric=full);
x:   all equations are linear - using the linear parametric solver
Parametric:   # of equations is:   1
Parametric:   best equation / unknown   2*a^2*b-c-b-a+2*b^2*a+2*a^2*c+2*a*c^2+2
*b^2*c+4*a*c*b+2*b*c^2, d, -1
Parametric:   backsubstitution at:   1
{
{ [{d =
       2                    2        2          2      2                    2
    2 a  b - c - b - a + 2 b  a + 2 a  c + 2 a c  + 2 b  c + 4 a c b + 2 b c }]
               2      2                  2    2      2        2
    , - s/2 + a  b + a  c + 2 a c b + a c  + b  a + b  c + b c  = 0
                  2      2                  2    2      2        2
    [] , - s/2 + a  b + a  c + 2 a c b + a c  + b  a + b  c + b c  <> 0

Yet, I think that a full documentation of the algorithms used and their implementation would avoid a lot of speculations, and help finding bugs and devising improvements.

@Carl Love 

Yes, this one has been reported many times. Well, Bryon says that he hears, but for practical matters there is no difference...

In this situation, I took the habit of saving the html source of many of my posts before preview or submit, in particular those including less and family. 

@Carl Love 

Yes, this one has been reported many times. Well, Bryon says that he hears, but for practical matters there is no difference...

In this situation, I took the habit of saving the html source of many of my posts before preview or submit, in particular those including less and family. 

@Markiyan Hirnyk 

The calculation of limits is an intrinsic part of the computation of definite integrals using FTOC. And Jacques has described it as a problem harder than the original integration, with holes in its theory ( see FTOC1, FTOC2, FTOC3). The problem is that a large part of the definite integrals are computed by the FTOC method (probably 80% or more). So, bugs in limit or MultiSeries:-limit as in this example have potentially serious consequences.

I would rather confirm that there are several bugs here. For the case of the symbolic integral, I find that a cleaner trace of the problems in the computation of the upper limit is generated by MultiSeries:-limit, as requested by method FTOCMS. So, see first the output produced by:

trace(MultiSeries:-limit);
f := (k+5)/sqrt(k^7+k^2):
int( f, k=1..infinity ,method=ftocms);

Here, in the computation of the limit at u->infinity, a series expansion is produced for the primitive function of the form constant-5*ln(1/u)+O(u^(3/2)), which is wrong and generates the fake limit of -infinity. This expansion is produced by the internal procedure MultiSeries:-`multiseries/multiseries`.

@Mac Dude 

OK. But note that Preben should not be blamed for any problem with applyrule1 :)

@Mac Dude 

OK. But note that Preben should not be blamed for any problem with applyrule1 :)

@Preben Alsholm 

I see, but I would not go overwriting the library version. May be that there is no problem for the procedure applyrule itself with your proposal. But as I see it, the PatternMatching package is so buggy (besides the undocumentation and unit test problems) that trying to patch it may be too risky. So, I prefer exploring different design ideas independently. That is why I have chosen a different name.

@Preben Alsholm 

I see, but I would not go overwriting the library version. May be that there is no problem for the procedure applyrule itself with your proposal. But as I see it, the PatternMatching package is so buggy (besides the undocumentation and unit test problems) that trying to patch it may be too risky. So, I prefer exploring different design ideas independently. That is why I have chosen a different name.

I agree, integration is one of my suggestions in this thread. And I think that one of the points that need investigation is how to decide quickly whether a symbolic computation is difficult enough so that going to a Grid parallelization is still advantageous despite that overhead.

I agree, integration is one of my suggestions in this thread. And I think that one of the points that need investigation is how to decide quickly whether a symbolic computation is difficult enough so that going to a Grid parallelization is still advantageous despite that overhead.

Yes, of course, the IntegralTransform LookUp Integrator is restricted to those integrals that play as transforms. And actually, the currently implemented lookup methods seldom succeed after my statistics. So, I think, a significant upgrade of these methods would be needed to make any practical difference. On the other hand, the method FTOC takes by far the largest share of successes. And actually, it is not so hard to extend it to currently failing cases by hacking the indefinite integration stage, just adding a rule based integration routine, as I have shown here. 

Marko, my coment above is all about the computation of symbolic definite integrals, where the problem resides in this case. Numeric computation of these integrals by evalf(Int(...)) follows a different, independent computation path, so that it is no surprise that it yields the expected results. Indeed, bugs or other problems may occur in numerical integration, but when they occur, most likely they will be unrelated. This is the main reason why a numeric cross check is frequently useful.

That the method FTOCMS yields more nonzero results than method FTOC simply means that these computations hit more bugs in MultiSeries:-limit than in limit. You may look what it does in one of these cases when computing lateral limits at each jump , e.g. by:

trace(MultiSeries:-limit):
qms(3);
{--> enter MultiSeries:-limit, args = -1/9/(2*exp(I*theta)-1)-2/9*ln(2*exp(I*
theta)-1)+1/18*(4*exp(I*theta)-2)/(4*exp(I*theta)^2+2*exp(I*theta)+1)+2/9*3^(1/
2)*arctan(1/6*(8*exp(I*theta)+2)*3^(1/2))+1/9*ln(4*exp(I*theta)^2+2*exp(I*theta
)+1), theta = Pi, left
                    _EnvMultiSeriesPiecewiseAnswers := false
                     _EnvMaxMultiSeriesPiecewiseLevel := 4
                     _EnvMaxMultiSeriesBranchCutLevel := 4
                        _EnvMaxMultiSeriesZeroLevel := 4
                                  x := theta~
                                    pt := Pi
[...] 

If you have time and patience, you may discover where the errors are located...

The first point to comment is that these integrals are being computed by method FTOC.

infolevel[IntegrationTools]:=3:
q(5);	
Definite Integration:   Integrating expression on theta=0..2*Pi
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
memory used=40.2MB, alloc=44.0MB, time=0.61
Definite Integration:   Method ftoc succeeded.
Definite Integration:   Finished sucessfully.
                                    -8
                                    -- I Pi
                                    25

And a well known problem is that the algorithms used for the computation of a primitive function frequently produce piecewise continuous functions, so that (basically) the integral has to be computed piecewise and the pieces added. See the plot for this example:

F:=n->Int(1/(1-2^n*exp(I*theta*n))^2*2*I*exp(I*theta), theta);
F5:=value(F(5));
plot([Re,Im](F5), theta=0..2*Pi,color=[red,blue]);

As you see, there are several jumps in the middle of the interval, and for each of them left and right limits have to be computed. Most likely one or more of these limits is computed wrongly. These computations for the method FTOC use the command limit. Compare with the results produced by  the method FTOCMS that uses the command MultiSeries:-limit instead:

qms := n -> int(1/(1-2^n*exp(I*theta*n))^2*2*I*exp(I*theta), theta=0..2*Pi,method=ftocms);
seq(qms(n), n=1..6);
memory used=504.9MB, alloc=210.0MB, time=7.90
                                          -8       -5
                      0, 0, -4/9 I Pi, 0, -- I Pi, -- I Pi
                                          25       36

May be that a stronger contour integration method could help with these limitations of FTOC. But I do not have evidence of any CAS implementing it successfully.

@Markiyan Hirnyk 

Indeed, and the paternalistic tone of this document is something that I dislike sharply.