I always use Shift + Enter. After ?worksheet,reference,hotwin or ?worksheet,reference,hotunix :

Shift + Enter              Soft New Line

It inserts a new line both in 1-D or 2-D input. For the latter, it produces this space feature.

On the other hand, Ctrl + Enter inserts a page break for me. And this is what the above linked help pages state.

I always use Shift + Enter. After ?worksheet,reference,hotwin or ?worksheet,reference,hotunix :

Shift + Enter              Soft New Line

It inserts a new line both in 1-D or 2-D input. For the latter, it produces this space feature.

On the other hand, Ctrl + Enter inserts a page break for me. And this is what the above linked help pages state.

@acer 

Certainly, I can reproduce the curves appearing by panning a bit.

I have opened with Maple 16.01 Standard GUI the worksheet saved with Maple 16.02 Standard GUI (where some curves are not shown), and also interestingly all the curves are shown. Yet a grid is displayed, as if gridlines=true had been used. It looks like as if plot layers have changed and those curves are located in a hidden layer. 

Tested on Linux Mint 13 32-bit.

@acer 

Certainly, I can reproduce the curves appearing by panning a bit.

I have opened with Maple 16.01 Standard GUI the worksheet saved with Maple 16.02 Standard GUI (where some curves are not shown), and also interestingly all the curves are shown. Yet a grid is displayed, as if gridlines=true had been used. It looks like as if plot layers have changed and those curves are located in a hidden layer. 

Tested on Linux Mint 13 32-bit.

I have run exactly your code in Maple 16.02 Standard GUI with plot output set inline. Indeed, I get plots with curves shown or not as you say. Then, I have saved this worksheet to a Classic worksheet format (mws), accepted at the warnings about missing features, and then opened this worksheet with Maple 16.02 Classic GUI. Interestingly, all the curves are shown (no need of a rerun). So, the stuff is there but not shown...It sounds like a regression bug in the Standard GUI plot driver.

I have run exactly your code in Maple 16.02 Standard GUI with plot output set inline. Indeed, I get plots with curves shown or not as you say. Then, I have saved this worksheet to a Classic worksheet format (mws), accepted at the warnings about missing features, and then opened this worksheet with Maple 16.02 Classic GUI. Interestingly, all the curves are shown (no need of a rerun). So, the stuff is there but not shown...It sounds like a regression bug in the Standard GUI plot driver.

I think that this issue is the domain overriding "feature" introduced in Maple 16, as described e.g. in this thread.

I think that this issue is the domain overriding "feature" introduced in Maple 16, as described e.g. in this thread.

For both sums, Maple uses a different algorithm to your hand calculation in the linked page. For s1, it yields a simple result in terms of elementary  functions by using the indefinite sumation method, while this method fails for s2. What succeeds for the later is the method of hypergeometric functions, which produces that complicated result in terms of special functions. The question stands whether the method of indefinite sumation could be improved for handling s2.

You can inspect the different methods tried in each case this way:

infolevel[SumTools]:=5:
s1 := sum( 1/(n^2+a), n=1..infinity) assuming a>0;
sum:   "process the input arguments"
sum:   "definite sum"
ClosedForm:   "try the front-end to compute simple definite sums"
ClosedForm:   simple definite summations
ClosedForm:   "try the method of integral representation"
ClosedForm:   "try the method of first computing the indefinite sum"
ClosedForm:   infinite summation
Indefinite:   "process the input arguments"
ClosedForm:   "handle floats"
ClosedForm:   "indefinite summation"
ClosedForm:   "indefinite summation completed"
                                             1/2       1/2
                                -Pi coth(Pi a   ) a + a
                     s1 := -1/2 --------------------------
                                            3/2
                                           a

s2 := sum((-1)^(n+1)/(n^2+a), n=1..infinity) assuming a>0;
sum:   "process the input arguments"
sum:   "definite sum"
ClosedForm:   "try the front-end to compute simple definite sums"
ClosedForm:   simple definite summations
ClosedForm:   "try the method of integral representation"
ClosedForm:   "try the method of first computing the indefinite sum"
ClosedForm:   infinite summation
Indefinite:   "process the input arguments"
ClosedForm:   "handle floats"
ClosedForm:   "indefinite summation"
Hypergeometric:   "indefinite sum using hypergeometric method"
Gosper:   "Step 1 of Gosper's algorithm"
Gosper:   "Step 2 of Gosper's algorithm"
PolynomialNormalForm:   "construct the polynomial normal form"
Gosper:   "Step 3 of Gosper's algorithm"
Gosper:   "find non-zero polynomial solution"
SumDecomposition:   "calling dterm"
SumDecomposition:   "construct the RCF_1 for the certificate of T"
PolynomialNormalForm:   "construct the polynomial normal form"
PolynomialNormalForm:   "construct the polynomial normal form"
SumDecomposition:   "construct a regular description of T"
SumDecomposition:   "calling dcert"
SumDecomposition:   "using resultant method"
ClosedForm:   "indefinite summation failed"
ClosedForm:   
"try the method of converting the definite sum to hypergeometric functions"
ClosedForm:   definite summation using hypergeometric functions
ClosedForm:   definite summation using hypergeometric functions
      /
s2 := |- 1/2 I (1 + a)
      \
                               1/2                          1/2      /  1/2
    (1/2 Psi(1/2 - 1/2 I (I + a   )) - 1/2 Psi(-1/2 I (I + a   )))  /  a    +
                                                                   /
    1/2 I (1 + a)
                               1/2                          1/2      /  1/2\
    (1/2 Psi(1/2 - 1/2 I (I - a   )) - 1/2 Psi(-1/2 I (I - a   )))  /  a   |/(
                                                                   /       /
    1 + a)

It would be interesting to know which methods are used by Mathematica.

You have posted on this same issue four months ago. Bryon then said:  "It's definitely a bug and we'll look into it". Well, you know, these things take time... 

@Axel Vogt 

It seems rather that the builtin procedure modp does try proving the equations involving products of symbols, by calling the probabilistic equivalence tester testeq, but this routine fails. Its help page ?testeq somewhat explains in which cases it may fail (though it is a bit cryptic for my taste). In this case, shortly:

testeq(modp(n^2,n)=0) assuming n,posint;
                              FAIL

And showing the full trace:

trace(modp):
trace(testeq):
is(n^2 mod n =0) assuming n,posint;
execute modp, args = n^2, n
{--> enter testeq, args = modp(n^2,n)
                                            2
                             expr := modp(n~ , n~)
                                    e1 := []
                                   s := FAIL
                                   s := FAIL
                                   s := FAIL
                                   s := FAIL
                                   s := FAIL
                                   s := FAIL
                                   s := FAIL
                                      FAIL 
<-- exit testeq (now in is/solve) = FAIL}
{--> enter testeq, args = property/obj1
                             expr := property/obj1
<-- exit testeq (now in is/solve) = false}
execute modp, args = `property/obj1`^2, property/obj1
{--> enter testeq, args = modp(`property/obj1`^2,`property/obj1`)
                                            2
                  expr := modp(property/obj1 , property/obj1)
                                    e1 := []
                                   s := FAIL
                                   s := FAIL
                                   s := FAIL
                                   s := FAIL
                                   s := FAIL
                                   s := FAIL
                                   s := FAIL
                                      FAIL
<-- exit testeq (now in is/solve) = FAIL}
execute modp, args = 0, 2
execute modp, args = 1, 2
                                      FAIL

Certainly,"additive" equations like modp(2*n,n)=0 look like being handled directly by modp.

@Axel Vogt 

It seems rather that the builtin procedure modp does try proving the equations involving products of symbols, by calling the probabilistic equivalence tester testeq, but this routine fails. Its help page ?testeq somewhat explains in which cases it may fail (though it is a bit cryptic for my taste). In this case, shortly:

testeq(modp(n^2,n)=0) assuming n,posint;
                              FAIL

And showing the full trace:

trace(modp):
trace(testeq):
is(n^2 mod n =0) assuming n,posint;
execute modp, args = n^2, n
{--> enter testeq, args = modp(n^2,n)
                                            2
                             expr := modp(n~ , n~)
                                    e1 := []
                                   s := FAIL
                                   s := FAIL
                                   s := FAIL
                                   s := FAIL
                                   s := FAIL
                                   s := FAIL
                                   s := FAIL
                                      FAIL 
<-- exit testeq (now in is/solve) = FAIL}
{--> enter testeq, args = property/obj1
                             expr := property/obj1
<-- exit testeq (now in is/solve) = false}
execute modp, args = `property/obj1`^2, property/obj1
{--> enter testeq, args = modp(`property/obj1`^2,`property/obj1`)
                                            2
                  expr := modp(property/obj1 , property/obj1)
                                    e1 := []
                                   s := FAIL
                                   s := FAIL
                                   s := FAIL
                                   s := FAIL
                                   s := FAIL
                                   s := FAIL
                                   s := FAIL
                                      FAIL
<-- exit testeq (now in is/solve) = FAIL}
execute modp, args = 0, 2
execute modp, args = 1, 2
                                      FAIL

Certainly,"additive" equations like modp(2*n,n)=0 look like being handled directly by modp.

Actually, a reason for the failure of method elliptic to perform the integration is that the integrand is not recognized as that of an elliptic integral. This check is made in `int/ellalg/elltype`, and the relevant sector of its code is this one:

showstat(`int/ellalg/elltype`,8..14);
`int/ellalg/elltype` := proc(theexpr, Rdom, lvar)`int/ellalg/elltype`
local i, j, k, a, b, degn, degd, degset, elemparts, elemparts1, ellcomp, ellflag, ellparts, multterm, newdd, newexpr, newexprnn, newexprdd, newnn, newnnc, newterm1, newterm2, newvar, const, newvarlist, newvartable, nonellparts, nonellparts1, nrlist, pp, r, radextset3n, radextset3d, radextset4, radsymbol, radtable, q, radterm, redset, rlist, rsddeg, rsndeg, rtb, rte, rterm, rvar, rvarb, rvarbn, rvarbd, rvare, subsset, substerm1, substerm2, termi, thecont, theradbase, truncrte, workdd;
       ...
   8   newexprnn := numer(newexpr);
   9   newexprdd := denom(newexpr);
  10   radextset3n := `minus`(indets(newexprnn,radext(polynom(anything,lvar))),indets(newexprnn,radext(constant)));
  11   radextset3d := `minus`(indets(newexprdd,radext(polynom(anything,lvar))),indets(newexprdd,radext(constant)));
  12   radextset4 := `union`(radextset3n,radextset3d);
  13   if nops(radextset4) = 0 then
  14     return 'FAIL'
       end if;
       ...

As you see, the numerator and denominator of the integrand are checked whether they contain a radical of a polynomial in the integration variable. But in your example, the integrand has a radical of a ratio of polynomials, an expression of type `*` that fails the check. Then you can see that it works by changing the integrand so that it has the "admissible" form, but not by changing the integration limits to the unit interval:

int((3*v^2+4*v+2)*(-(3*v^2+2*v+1)^(1/2))/(3*v^2+8*v+4)^(1/2)/(1+2*v)^2,v = -2 .. -2/3,
method=elliptic);

       /     1/2               1/2 \
       |  3 2                 2    |
-1/3 I |- ------ - 3/2 arctan(----)| - 8/3 I EllipticK(1/3)
       \    2                  2   /
     + 8/3 I EllipticPi(-1/3, 1/3) + 3 I EllipticE(1/3)
             /   1/2               1/2 \
             |3 2                 2    |
     - 1/3 I |------ + 3/2 arctan(----)|
             \  2                  2   /

int((3*v^2+4*v+2)*(-(3*v^2+2*v+1)/(3*v^2+8*v+4))^(1/2)/(1+2*v)^2,v = 0 .. 1,
method=elliptic);

                        /     2          \1/2
           2            |  3 v  + 2 v + 1|
       (3 v  + 4 v + 2) |- --------------|
                        |     2          |
                        \  3 v  + 8 v + 4/
   int(--------------------------------------, v = 0 .. 1, method = elliptic)
                              2
                     (1 + 2 v)

And by the change of variable, you were lucky that the integrand turned into the admissible form. Well, this restriction to a radical of a poynomial may be a distraction in coding, or a weakness of the implemented algorithm. It is hard to know which is the case without access to the suitable documentation. Of course, it is even harder in the case of MMA, without access to its code.

Sadly, without proper documentation of the algorithms implemented and the code, I think that it is not possible for us (users) to know whether there is any reason, or it was just forgotten to be done. Yet, it seems to me likely that this is what happened. A list of the performed computations is obtained by:

infolevel[int]:=5:
J:=Int((3*v^2+4*v+2)*(-(3*v^2+2*v+1)/(3*v^2+8*v+4))^(1/2)/(1+2*v)^2,v = -2 .. -2/3);
value(J);

It seems like nowhere a change of variable taking the integral into the unit interval is tried.

@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.