Let me see if I can understand now your request. If Maple cannot evaluate by FTOC, it may be because: 1. the integrand has no primitive/antiderivative function, 2. the integrand has a primitive/antiderivative function, but Maple cannot find one, 3. Maple finds a wrong primitive function, 4. Maple finds a "correct" primitive function, possibly piecewise continuous, but fails at identifying the discontinuities or at computing the one-sided limits (at the limits of integration and/or the discontinuity points), producing no result or a wrong result.Your mention of special functions above suggests to me that you mean case 1. Yet, in practice, case 4. is quite relevant.

In any case, I do not have at this moment an example. Actually, I have in mind looking more carefully at the implementation of contour integration in Maple (but it depends on the availability of time). Knowing what it can and cannot do may allow answering that question more certainly (proper documentation of algorithms and implementation is much needed for these cases) . A priori, the probability of  the method contour succeeding when the other ones do not seems low because of its "status", after Jacques' description.

@Doug Meade 

Actually there are many examples. For instance see here the same integral computed by method ftoc and by method countour, two runs with each method, every run in an independent session (Maple 16.02 CLI on Linux 32-bit):

CodeTools:-Usage(int(1/(X^2+X+1),X=-infinity..infinity,method=ftoc));
memory used=1.94MiB, alloc change=0 bytes, cpu time=33.00ms, real time=34.00ms
                                         1/2
                                   2 Pi 3
                                   ---------
                                       3

CodeTools:-Usage(int(1/(X^2+X+1),X=-infinity..infinity,method=ftoc));
memory used=1.94MiB, alloc change=0 bytes, cpu time=48.00ms, real time=48.00ms
                                         1/2
                                   2 Pi 3
                                   ---------
                                       3
                                                                              
CodeTools:-Usage(int(1/(X^2+X+1),X=-infinity..infinity,method=contour));
memory used=1.58MiB, alloc change=0 bytes, cpu time=29.00ms, real time=31.00ms
                                         1/2
                                   2 Pi 3
                                   ---------
                                       3

CodeTools:-Usage(int(1/(X^2+X+1),X=-infinity..infinity,method=contour));
memory used=1.58MiB, alloc change=0 bytes, cpu time=32.00ms, real time=31.00ms
                                         1/2
                                   2 Pi 3
                                   ---------
                                       3

The interesting thing is that the method contour is more efficient here than the method ftoc. Yet, if you issue the int statement without a specification of the method, as in the normal call of this command, the method ftoc is the one used as it succeeds and is located earlier in the list of definite integrator methods. Moreover, as the method contour is located at the end of this list, it has little chance of doing something in normal calls, even if it were capable and more efficient as in this simple example. 

Compared with that comment, the symptoms here are different:

> f:=sqrt(-8*cos(t)*sin(t)+5):a:=0:b:=2*Pi:
> `int/definite/elliptic`(f,t,a,b,{});
memory used=37.4MB, alloc=43.1MB, time=0.60
                                      FAIL
> `int/definite/ftoc`(f,t,a,b,{}); 
                                       0

So, it may be a different bug yet to be fixed.

Compared with that comment, the symptoms here are different:

> f:=sqrt(-8*cos(t)*sin(t)+5):a:=0:b:=2*Pi:
> `int/definite/elliptic`(f,t,a,b,{});
memory used=37.4MB, alloc=43.1MB, time=0.60
                                      FAIL
> `int/definite/ftoc`(f,t,a,b,{}); 
                                       0

So, it may be a different bug yet to be fixed.

I do not see the point of that link.

Another place is stated at the end of ?assuming,details > Description:

The assuming command does not scan Maple programs regarding the potential presence of assumed variables. To compute taking into account assumptions on variables found in the bodies of programs, use assume.

Another place is stated at the end of ?assuming,details > Description:

The assuming command does not scan Maple programs regarding the potential presence of assumed variables. To compute taking into account assumptions on variables found in the bodies of programs, use assume.

I have inspected the localhost TCP stream of the conversation between the Maple 16.02 Standard GUI and the C kernel, when executing the OP's commands on Linux 32-bit. As I have stated below, no output occurs in this platform (instead of the  symbol `Non-fatal error...`). Yet, what I observe as result from the C kernel for the GUI is the expected procedure in Typesetting call form. So, that it does not print is an issue purely of the Java sector of the system.

I do not have a 64-bit setup to check this issue at this moment. But may be that the symbol that you observe is produced by the Java kernel instead.

I have inspected the localhost TCP stream of the conversation between the Maple 16.02 Standard GUI and the C kernel, when executing the OP's commands on Linux 32-bit. As I have stated below, no output occurs in this platform (instead of the  symbol `Non-fatal error...`). Yet, what I observe as result from the C kernel for the GUI is the expected procedure in Typesetting call form. So, that it does not print is an issue purely of the Java sector of the system.

I do not have a 64-bit setup to check this issue at this moment. But may be that the symbol that you observe is produced by the Java kernel instead.

John,

It depends, "poplar" with whom? And the important thing: does it make the things done?

@PatrickT 

Look here at the arguments that algsubs receives:

trace(algsubs):
f4 := algsubs(A^2+1 = M^2, f) assuming M > 0;
{--> enter algsubs, args = A^2+1 = M^2, A^2-2*(A^2+1)^(1/2)+1
...

You can see here the "nonexecuting" power constructor `^`, rather than sqrt, in (A^2+1)^(1/2). So, at this stage, no profit can be taken from the property M>0. And a further step is needed, involving a command like simplify that can make something with this property.

Yet, we could ask what about an extension of the capability of algsubs, making it react to assumptions by an optional stage that calls simplify say. Moreover, note that the original assumption by the OP is A>0, from which this extended algsubs could apply to the substitution equation, deducing A^2+1>0 hence M^2>0, and use this property for obtaining M^2-2*abs(M) in one go. It is a pity that the development of algsubs has been frozen for over 15 years.

@PatrickT 

Look here at the arguments that algsubs receives:

trace(algsubs):
f4 := algsubs(A^2+1 = M^2, f) assuming M > 0;
{--> enter algsubs, args = A^2+1 = M^2, A^2-2*(A^2+1)^(1/2)+1
...

You can see here the "nonexecuting" power constructor `^`, rather than sqrt, in (A^2+1)^(1/2). So, at this stage, no profit can be taken from the property M>0. And a further step is needed, involving a command like simplify that can make something with this property.

Yet, we could ask what about an extension of the capability of algsubs, making it react to assumptions by an optional stage that calls simplify say. Moreover, note that the original assumption by the OP is A>0, from which this extended algsubs could apply to the substitution equation, deducing A^2+1>0 hence M^2>0, and use this property for obtaining M^2-2*abs(M) in one go. It is a pity that the development of algsubs has been frozen for over 15 years.

I do not agree.

Printed manuals are better for my eyes.

It is not clear that there is a total carbon footprint reduction. Not cutting down trees and not shipping books will reduce carbon emissions on that side. But having to read those books electronically will increase the carbon footprint at this side (in particular more production of electricity for computers, air conditioning, etc).

And economically, it means a transfer of costs from Maplesoft to the users.

So, I see this decision as bad.

@Carl Love 

It would be interesting to know why you do not get the space. For instance, typing in 2-D input mode:

a; 
b; 

with a Ctrl + Enter soft new line, I get the following TypeMK background code for this input:

`Typesetting:-mrow`(`Typesetting:-mi`("a", italic = "true", mathvariant = "italic"), 
`Typesetting:-mo`(";", mathvariant = "normal", fence = "false", separator = "true", 
stretchy = "false", symmetric = "false", largeop = "false", movablelimits = "false", 
accent = "false", lspace = "0.0em", rspace = "0.2777778em"), 
`Typesetting:-mspace`(height = "0.0ex", width = "0.0em", depth = "0.0ex", 
linebreak = "newline"), `Typesetting:-mo`(" ", mathvariant = "normal", 
fence = "false", separator = "false", stretchy = "false", symmetric = "false", 
largeop = "false", movablelimits = "false", accent = "false", lspace = "0.0em", 
rspace = "0.0em"), `Typesetting:-mi`("b", italic = "true", mathvariant = "italic"), 
`Typesetting:-mo`(";", mathvariant = "normal", fence = "false", separator = "true", 
stretchy = "false", symmetric = "false", largeop = "false", movablelimits = "false", 
accent = "false", lspace = "0.0em", rspace = "0.2777778em"))

Note here the code corresponding the inserted space: `Typesetting:-mo`(" ",....). I wonder what TypeMK code you get instead.

@Carl Love 

It would be interesting to know why you do not get the space. For instance, typing in 2-D input mode:

a; 
b; 

with a Ctrl + Enter soft new line, I get the following TypeMK background code for this input:

`Typesetting:-mrow`(`Typesetting:-mi`("a", italic = "true", mathvariant = "italic"), 
`Typesetting:-mo`(";", mathvariant = "normal", fence = "false", separator = "true", 
stretchy = "false", symmetric = "false", largeop = "false", movablelimits = "false", 
accent = "false", lspace = "0.0em", rspace = "0.2777778em"), 
`Typesetting:-mspace`(height = "0.0ex", width = "0.0em", depth = "0.0ex", 
linebreak = "newline"), `Typesetting:-mo`(" ", mathvariant = "normal", 
fence = "false", separator = "false", stretchy = "false", symmetric = "false", 
largeop = "false", movablelimits = "false", accent = "false", lspace = "0.0em", 
rspace = "0.0em"), `Typesetting:-mi`("b", italic = "true", mathvariant = "italic"), 
`Typesetting:-mo`(";", mathvariant = "normal", fence = "false", separator = "true", 
stretchy = "false", symmetric = "false", largeop = "false", movablelimits = "false", 
accent = "false", lspace = "0.0em", rspace = "0.2777778em"))

Note here the code corresponding the inserted space: `Typesetting:-mo`(" ",....). I wonder what TypeMK code you get instead.