Miscellaneous bugs |
Every large system--whether it be a jetliner, the income tax code, or a complex computer program--has errors. People who fly, pay taxes, or use computers naturally feel unhappy about glitches and gremlins in critical systems. On the other hand, Bill Gates became the richest man on the planet by selling products that do not work correctly.
Maple sometimes mishandles the signum
function. For example, suppose that you ask Maple for
the limit at infinity of a first-degree polynomial:
restart: f:=x->a*x+5: limit(f(x), x=infinity); signum(a) infinity
Maple's answer is valid when a is different from zero, but when a=0, the answer should be 5. The following commands show that Maple really does get it wrong when a=0:
restart: f:=x->a*x+5: assume(a=0): limit(f(x), x=infinity); 0
The command limit(subs(a=0,f(x)), x=infinity);
does produce the correct answer 5.
We teach our calculus students that they should not use the same letter to denote both the dummy variable of integration and the limit of integration. Preben Alsholm noted in a message to the newsgroup comp.soft-sys.math.maple on 17 May 2001 that Maple is inconsistent about such matters, as the following examples show:
> int(1/x, x=1..x); Error, (in limit) invalid limiting point > int(x^2, x=1..x); 3 1/3 x - 1/3
Here is an elementary sum of binomial coefficients that Maple gets wrong. This is a modification of an example posted to the Maple User Group mailing list by Robert Israel in response to a question from David Lutterkort.
> assume(n>0,m>0); S:=Sum( (1-i)*binomial(n+m,n+i), i=0..m): subs({n=2,m=2},value(S)): value(%); 6 > subs({n=2,m=2},S): value(%); 5
Suppose that you assign a calculus class the problem of determining the convergence behavior of the infinite series whose general term an equals the reciprocal of the cube of the greatest integer less than or equal to the square-root of n, that is, an = [n1/2]-3, where the brackets denote the greatest integer function. What you hope the students will say is that for large n, the greatest integer function has little effect on the size of an, so the series must converge by comparison with the sum of n-3/2 (in other words, the limit comparison test applies). Here is how Maple mishandles the problem:
a := n -> floor(sqrt(n))^(-3): evalf(sum(a(n), n=1..4)); evalf(sum(a(n), n=1..infinity)); 3.125000000 3.000000000
The first four terms of the series are 1, 1, 1, 1/8, which already have a sum larger than what Maple claims for the sum of the whole series!
Miscellaneous bugs |