Ian Thompson has written a new book, Understanding Maple.

I've been browsing through the book and am quite pleased with what I've read so far. As a small format paperback of just over 200 pages it packs in a considerable amount of useful information aimed at the new Maple user. It says, "At the time of writing the current version is Maple 2016."

The general scope and approach of the book is explained in its introduction, which can currently be previewed from the book's page on amazon.com. (Click on the image of the book's cover, to "Look inside", and then select "First Pages" in the "Book sections" tab in the left-panel.)

While not intended as a substitute for the Maple manuals (which, together, are naturally larger and more comprehensive) the book describes some of the big landscape of Maple, which I expect to help the new user. But it also explains how Maple is working at a lower level. Here are two phrases that stuck out: "This book takes a command driven, or programmatic, approach to Maple, with the focus on the language rather than the interface", followed closely by, "...the simple building blocks that make up the Maple language can be assembled to solve complex problems in an efficient way."

Let us consider 

Student[Precalculus]:-LimitTutor(sqrt(x), x = 2);

One expects a nice illustration of the result sqrt(2). But instead of that one reads "f(x) approaches 1.41 as x approaches 2". This is simply clueless and forms a wrong understanding of limits. It should also be noticed that all the entries (left, 2-sided, and right) produce the same animation. The same issue with other limits I tried, e.g.

Student[Precalculus]:-LimitTutor(sqrt(x), x = 1);

. I think this command should be completely rewritten or excluded from Maple. 

Let us look in RealDomain and then in the RealDomain:-solve command. One is addressed to the usual solve command. The commands of the RealDomain package are not still documented since Maple 7 when the package was introduced. There is a general description only 

• By default, Maple performs computations under the assumption that the underlying number system is the complex field. The RealDomain package provides an environment in which computations are performed under the assumption that the basic underlying number system is the field of real numbers.
• Results returned by procedures are postprocessed by discarding values containing any detectable non-real answers or replacing them with undefined where appropriate.

The above is not enough. Here is an example which confuses me: 

RealDomain:-solve(exp(I*x) = -1, AllSolutions);
NULL

though 

solve(exp(I*x) = -1, AllSolutions);
                         Pi (2 _Z1 + 1)

and 

RealDomain:-solve(exp(I*x) = -1);
                               Pi

I lie awake thinking about that. Maplesoft staff help me!

Let us consider 

Statistics:-Mode(Binomial(n, p));
                        floor((1 + n) p)

Up to Wiki, the output is not correct. Simply no words.

There were recently submitted a dozen Maple bugs by me and others. Maplesoft have brought no responses. They keep strategic silence. True merit is not afraid of criticism.

Download Bug_in_Statistics_PDF.mw

Let us consider 

restart; J := int(cos(a*x)^2/(x^2-1), x = -infinity .. infinity, CPV);
-(1/4)*Pi*sin(2*a)*csgn(I*a)-(1/4)*Pi*sin(2*a)*csgn(I/a)

This result is not true for a=I:

eval(J, a = I);
                               0

In this case the integral under consideration diverges because of 

cos(I*x)^2;
                                
                            cosh(x) ^2

Let us consider 

maximize(int(exp(-x^4), x = k .. 3*k), location);

Error, (in maximize) invalid input: iscont expects its 1st argument, f, to be of type algebraic, but received x = k .. 3*k
whereas the expected output is 

[(2*((1/40)*GAMMA(1/4, (1/80)*ln(3))*5^(1/4)*ln(3)^(3/4)-(1/40)*GAMMA(1/4, (81/80)*ln(3))*5^(1/4)*ln(3)^(3/4)))*5^(3/4)*(1/ln(3))^(3/4), [k = (1/10)*10^(3/4)*ln(3)^(1/4)]]

as Mma 11 produces. The following 

RealDomain:-solve(diff(int(exp(-x^4), x = k .. 3*k), k));
  -(1/10)*5^(3/4)*ln(3)^(1/4), (1/10)*5^(3/4)*ln(3)^(1/4)

is not a workaround because of 

int(exp(-x^4), x = (1/10)*5^(3/4)*ln(3)^(1/4) .. (3/10)*5^(3/4)*ln(3)^(1/4));
  FAIL

Let us consider 

MultiSeries:-series(Psi((2*x+1)/(2*x))-Psi((x+1)/(2*x)), x = 0);

x-(1/2)*x^2+(1/4)*x^4-(1/2)*x^6 +O(x^7)

The above result contradicts 

MultiSeries:-limit(diff(Psi((2*x+1)/(2*x))-Psi((x+1)/(2*x)), x), x = 0);
                           undefined
MultiSeries:-limit((Psi((2*x+1)/(2*x))-Psi((x+1)/(2*x)))/x, x = 0, right);
                               1
MultiSeries:-limit((Psi((2*x+1)/(2*x))-Psi((x+1)/(2*x)))/x, x = 0, left);
                           undefined
plot((Psi((2*x+1)/(2*x))-Psi((x+1)/(2*x)))/x, x = -0.1e-1 .. 0.1e-2, discont, y = -5 .. 5);

restart; with(Statistics):
X := RandomVariable(Normal(0, 1)): Y := RandomVariable(Uniform(-2, 2)):
Probability(X*Y < 0);

crashes my comp in approximately 600 s. Mma produces 1/2 on my comp in 0.078125 s.

Let us consider

with(Statistics):
X1 := RandomVariable(Normal(0, 1)):
X2 := RandomVariable(Normal(0, 1)):
X3 := RandomVariable(Uniform(0, 1)): 
X4 := RandomVariable(Uniform(0, 1)):
Z := max(X1, X2, X3, X4); CDF(Z, t);

int((1/2)*(_t0*Heaviside(_t0-1)-_t0*Heaviside(_t0)-Heaviside(1-_t0)*Heaviside(-_t0)+Heaviside(-_t0)+Heaviside(1-_t0)-1)*(1+erf((1/2)*_t0*2^(1/2)))*(2^(1/2)*Heaviside(_t0-1)*exp(-(1/2)*_t0^2)*_t0-2^(1/2)*Heaviside(_t0)*exp(-(1/2)*_t0^2)*_t0-2^(1/2)*Heaviside(-_t0)*Heaviside(1-_t0)*exp(-(1/2)*_t0^2)-Pi^(1/2)*undefined*erf((1/2)*_t0*2^(1/2))*Dirac(_t0)-Pi^(1/2)*undefined*erf((1/2)*_t0*2^(1/2))*Dirac(_t0-1)+2^(1/2)*Heaviside(-_t0)*exp(-(1/2)*_t0^2)+2^(1/2)*Heaviside(1-_t0)*exp(-(1/2)*_t0^2)-Pi^(1/2)*undefined*Dirac(_t0)-Pi^(1/2)*undefined*Dirac(_t0-1)+Pi^(1/2)*Heaviside(_t0-1)*erf((1/2)*_t0*2^(1/2))-Pi^(1/2)*Heaviside(_t0)*erf((1/2)*_t0*2^(1/2))-exp(-(1/2)*_t0^2)*2^(1/2)+Pi^(1/2)*Heaviside(_t0-1)-Pi^(1/2)*Heaviside(_t0))/Pi^(1/2), _t0 = -infinity .. t)

whereas Mma 11 produces the correct piecewise expression (see that here screen15.11.16.docx).

Edit. Mma output.

Let us consider 

J := int(x^n/sqrt(1+x^n), x = 0 .. 1) assuming n > 0;

2*(2^(1/2)-hypergeom([1/2, 1/n], [(n+1)/n], -1))/(2+n)

limit(J,n=infinity);
FAIL
MultiSeries:-limit(J,n=infinity);
FAIL

Mma 11 finds the limit is zero. Hope one feels the difference.

limit((x^2-1)*sin(1/(x-1)), x = infinity, complex);
infinity-infinity*I
MultiSeries:-limit((x^2-1)*sin(1/(x-1)), x = infinity, complex);
infinity

whereas the same outputs are expected. The help http://www.maplesoft.com/support/help/Maple/view.aspx?path=infinity&term=infinity does not shed light on the problem. Here are few pearls:

• infinity is used to denote a mathematical infinity, and hence it is usually used as a symbol by itself or as -infinity.
• The quantities infinity, -infinity, infinity*I, -infinity*I, infinity + y*I, -infinity + y*I, x + infinity*I and x - infinity*I, where x and y are finite, are all considered to be distinct in Maple. However, all 2-component complex numerics in which both components are infinity are considered to be the same (representing the single point at the "north pole" of the Riemann sphere).
• The type cx_infinity can be used to recognize this "north pole" infinity.

Let us consider 

MmaTranslator:-FromMma(" Table[0,{n=10},{m=2}]");

[seq([seq(0,i=1..(m := 2))],j=1..(n := 10))]

The above result is syntactically incorrect in Maple language. The translation should be 

Matrix(10,2)
#or
[seq([seq(0,i=1.. 2)],j=1..10)]

up to the Mmma's result

Table[0, {n = 10}, {m = 2}]

{{0, 0}, {0, 0}, {0, 0}, {0, 0}, {0, 0}, {0, 0}, {0, 0}, {0, 0}, {0,0}, {0, 0}}

Another bug is as follows.

MmaTranslator:-FromMma("Sinc[x]");

Sinc(x)

whereas the expected result is piecewise(x=0,1,sin(x)/x) up to http://reference.wolfram.com/language/ref/Sinc.html

In general, the MmaTranslator package is outdated. It often returns working Mma's commands as incorrect (Concrete examples are long and need a context. These may be exposed on demand.). The question arises about the quality of other Maple translations. 

The command

plots:-implicitplot(evalc(argument((1+x+I*y)/(1-x-I*y))) <= (1/4)*Pi, x = -5 .. 5, y = -5 .. 5, crossingrefine = 1, gridrefine = 2, rational = true, filled, signchange = true, resolution = 1000);

produces an incorrect result

in view of

evalf(argument((1-4+4*I)/(1+4-4*I)));
                          2.889038378

There is a workaround 

plots:-inequal(evalc(argument((1+x+I*y)/(1-x-I*y))) <= (1/4)*Pi, x = -5 .. 5, y = -5 .. 5);

The command 

restart; st := time(): FunctionAdvisor(EllipticE); time()-st;

produces the result on my comp in 805.484 s. Too much time.