149
$\begingroup$

In the course of doing mathematics, I make extensive use of computer-based calculations. There's one CAS that I use mostly, even though I occasionally come across out-and-out wrong answers.

After googling around a bit, I am unable to find a list of such bugs. Having such a list would help us remain skeptical and help our students become skeptical. So here's the question:

What are some mathematical bugs in computer algebra systems?

Please include a specific version of the software that has the bug. Please note that I'm not asking for bad design decisions, and I'm not asking for a discussion of the relative merits of different CAS's.

Improve this question
$\endgroup$
7
  • 8
    $\begingroup$ Judging by the answers below, maybe a better question would be not "What are some bugs?" but "Which websites have the most useful/comprehensive lists of bugs?". $\endgroup$
    – David E Speyer
    Commented Jan 12, 2010 at 15:36
  • 29
    $\begingroup$ This is possibly some sort of record: Richard Parker told me that he once typed "isprime(2)" as his first ever query to a certain computer algebra system, and got the reply "2 is not prime". He also claimed, probably correctly, that he could find a bug in any computer algebra system within 5 minutes. $\endgroup$
    – Richard Borcherds
    Commented Aug 9, 2010 at 14:27
  • 4
    $\begingroup$ Richard's story is really surprising, because all systems I know will look up small primes in a table, so someone left off 2 from that table. It's possible, I guess, but really a silly goof. $\endgroup$
    – Thierry Zell
    Commented Apr 27, 2011 at 16:51
  • $\begingroup$ Kevin thanks. pari has unconditional thue solver too (the second thue() in the example) and it agrees with your solutions. pari's GRH conditional solver is faster than the unconditional (in some cases the unconditional might be undoable). Do you happen to know other GRH conditional thue solver implementation? $\endgroup$
    – joro
    Commented Jul 13, 2012 at 5:19
  • $\begingroup$ RE: GRH thue solver. Pari developers are investigating the problem. The thread is here: pari.math.u-bordeaux.fr/archives/pari-dev-1207/msg00008.html. Developer wrote "I do not understand where the problem (missing solution) comes from yet. It looks like a mathematical bug so far...". The pari thue code is relatively small. $\endgroup$
    – joro
    Commented Jul 16, 2012 at 5:46

38 Answers 38

Reset to default
1
2
4
$\begingroup$

We found some interesting bugs in Mathematica's integration software on this thread.

To wit, set

integral[m_,n_] = Integrate[Log[2+Cos[2Pi x]+Cos[2Pi y]] Cos[2Pi m x] Cos[2Pi n y],
                      {x, 0, 1}, {y, 0, 1}];

Then integral[1,1] should be $1/2-2/\pi$, but Mathematica 8.0.1 returns $1/2+2/\pi$. Values for other $m$ and $n$ are also wrong (see the question linked above), as can be quickly verified by replacing the "Integrate" command with "NIntegrate".

Curiously, if one changes the limits of integration to {x,-1/2,1/2} and {y,-1/2,1/2}, then the correct answers appear.

Improve this answer
$\endgroup$
2
  • 2
    $\begingroup$ I don't know how Mathematica handles this integral, but I wonder if it's somehow related to the problems mentioned in Kurt's answer in dealing with branch cuts symbolically...in this case the problem is at the point $(1/2, 1/2)$ and moving the limits around moves this to a corner instead of the middle of the interval. $\endgroup$
    – Kevin P. Costello
    Commented Mar 7, 2012 at 20:56
  • 1
    $\begingroup$ This seems to have been fixed in the current version. $\endgroup$
    – J. M. isn't a mathematician
    Commented May 18, 2017 at 16:52
4
$\begingroup$

The PARI/GP Thue equations solver gives wrong results when they are conditional on GRH.

Affected are at least versions 2.5.1 (latest) and 2.4.3.

? p=x^3 - 18*x^2 + 81*x + 1;a=3^3
%1 = 27
? t=thue(thueinit(p,0),a);[#t,t] \\ conditional on GRH
%2 = [3, [[0, 3], [3, 0], [19, 2]]]
? t=thue(thueinit(p,1),a);[#t,t] \\ uncoditional
%3 = [4, [[0, 3], [3, 0], [27, 3], [19, 2]]]

Found on the pari-dev mailing list http://permalink.gmane.org/gmane.comp.mathematics.pari.devel/3629.

Improve this answer
$\endgroup$
4
  • $\begingroup$ FYI, Mathematica has an unconditional Thue solver built in (I had something to do with that): the input Reduce[x^3 - 18 x^2 y + 81 x y^2 + y^3 == 27, Integers]'' yields the output (x == 0 && y == 3) || (x == 3 && y == 0) || (x == 19 && y == 2) || (x == 27 && y == 3)''. $\endgroup$
    – Kevin O'Bryant
    Commented Jul 12, 2012 at 14:56
  • $\begingroup$ Kevin thanks. pari has unconditional thue solver too (the second thue() in the example) and it agrees with your solutions. pari's GRH conditional solver is faster than the unconditional (in some cases the unconditional might be undoable). Do you happen to know other GRH conditional thue solver implementation? $\endgroup$
    – joro
    Commented Jul 13, 2012 at 5:16
  • $\begingroup$ I'm not aware of any other GRH-conditional solver. The only place I imagine GRH being relevant is in the linear-forms-in-logarithms stage, and then it would only affect the initial bound on x. If that's correct, there really isn't any reason for the implementations to be different at all. Could the GRH bound actually come out below 27 (and therefore be missing a constant or worse)? $\endgroup$
    – Kevin O'Bryant
    Commented Jul 16, 2012 at 1:12
  • $\begingroup$ On the mailing list Bill says this was a bug in 2.3 which was fixed in 2.5.0. I can verify that it does not affect 2.8.0. $\endgroup$
    – Charles
    Commented Sep 20, 2016 at 13:44
3
$\begingroup$

As was noted for Sage, for any open source CAS you can just look up the issue tracker. For example, here's the list if all the issues in SymPy tracker with the WrongResult label: http://code.google.com/p/sympy/issues/list?q=label:WrongResult. Most of them are pretty rare. You're much more likely to hit a bug that just gives an error when it shouldn't, or that gives an unexpected, but not technically wrong (mathematically), result.

My advice is to double check your answer in some other way. The chances of the same bug manifesting itself in two different ways are almost zero. For example, you can check a result numerically, which will use a completely different algorithm from the symbolic version. Many CASs even have built in functions that do this for you.

Improve this answer
$\endgroup$
1
2
$\begingroup$

Wolfram Mathematica 7 routinely confuses sums with integrals.

Example 1:

DSolve[(-Log[Log[a]] f'[x] + f''[x])/(Log[a] f'[x]) == D[Sum[f[x], x], x], f[x], x]

g[x_] := f[x] /. s
g[x]

Checking the result by inserting it into the equation shows the result is incorrect:

(-Log[Log[a]] g'[x] + g''[x])/(Log[a] g'[x]) - D[Sum[g[x], x], x]

Example 2:

s=NDSolve[{0.9159460564995328*Derivative[1][f][x] == f[x]*Product[f[x], x], f[0] == 1}, f, {x, -1.9, 15}]

Plot[Evaluate[f[x] /. s], {x, -0.4, 1.5}, AspectRatio -> Automatic, AxesOrigin -> {0, 0}]

In Mathematica 8.0 this has been fixed (i.e. it will report inability to solve the equations.

Improve this answer
$\endgroup$
1
  • $\begingroup$ See other examples. $\endgroup$
    – Anixx
    Commented May 3, 2011 at 2:29
2
$\begingroup$

Mathematica 7.0.1 says that Sum[1/(k*Length[Divisors[k]]), {k, 1, n}] is the harmonic number $H_n$, which is clearly wrong. The correct answer is at An elementary number theoretic infinite series

Edit:

This is less a bug and more a misunderstanding of how to use Mathematica. The culprit is that Length[Divisors[k]] for k without a value evaluates to 1 (which is consistent with how Mathematica structurally treats expressions). The correct way to express the sum is

Sum[1/(k DivisorSigma[0, k]), {k, 1, n}]

which, as expected, now remains unevaluated.

Improve this answer
$\endgroup$
0
1
$\begingroup$

Not a bug but a difficulty for users:

I do often not really understand how assignements work for CAS:

Given a variable $a$ with value, say, $\pi$, set $b:=a$ and set now $a$ to, say, $e$. What is the value of $b$?

As I understand the answer depends sometimes on the context (working with symbolic variables, vectors, floating numbers etc.) and the exact behaviour is sometimes difficult to guess for me.

Improve this answer
$\endgroup$
5
  • 2
    $\begingroup$ Normally this should not be a matter of guessing. Somewhere the documentation should state whether the evaluation is call-by-value ($b=\pi$) or call-by-reference ($b=e$). $\endgroup$
    – darij grinberg
    Commented Apr 27, 2011 at 9:02
  • 6
    $\begingroup$ Maple and Mathematica are both call-by-value. What Roland is probably referring to is that Maple has some variables which have an entirely 'new' calling convention,last-name-evaluation: a cross between call-by-value and call-by-name. An LNE variable (like a table) will 'evaluate' all the way to a value and then BACKTRACK one level and return the last name encountered! The reason for this is purely for display purposes, as the name is preferred over a large value. This decision was made in 1982 (or so), when it made some sense, but now Maple is stuck with this. MMA has similar oddities too $\endgroup$
    – Jacques Carette
    Commented Apr 27, 2011 at 12:46
  • $\begingroup$ I would be great to leave the choice to to the user! $\endgroup$
    – Roland Bacher
    Commented Apr 27, 2011 at 13:45
  • 2
    $\begingroup$ @Roland, the problem with leaving the choice to the user would be that the same program would give different results for different users. $\endgroup$
    – JRN
    Commented Apr 28, 2011 at 1:04
  • $\begingroup$ Of course! Passing By Reference or Passing By Value?. One of the classes in your programming courses, though not the first one indeed..... $\endgroup$
    – Brethlosze
    Commented May 18, 2017 at 2:14
0
$\begingroup$

Sagemath and pari/gp disagree about the degree of the zero polynomial over arbitrary rings. Since pari/gp is proper subset of sagemath, this gives us inconsistency in sagemath.

Session:

sage: K.<x>=QQ[];K(0).degree()
-1
sage: gp.poldegree(K(0))
-oo
Improve this answer
$\endgroup$
1
-6
$\begingroup$

Here is a very simple common bug: ask your cas to solve in x the equation a x-´b = 0. Probably, the answer would bex = - b/a, that is wrong if a = 0. Most cas assume implicitly that a is not zero (Mathematica is an exception).

Improve this answer
$\endgroup$
1
2

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .