A random collection of bugs in Mathematica 7 and 7.0.1

November 23rd, 2009 | Categories: mathematica | Tags:

There was a discussion recently on comp.soft-sys.math.mathematica about maintaining a user-led Mathematica bug list and various solutions were proposed.  I have no desire (and certainly no time) to even try to maintain a ‘proper’ bug database for Mathematica but I am interested in maintaining a list of bugs that I personally find interesting and that I would like to see explained or fixed.

This post is that list.

First – some answers to potential questions.

Why are you doing this?  I thought you liked Mathematica.

I love Mathematica but, like all pieces of software, it is not perfect.  I find (some of) the imperfections interesting and since I get lots of hits from google every month from people looking for bugs in MATLAB, Mathematica, Maple, Mathcad etc then I assume that I am not alone.  Every bug that I discuss here will be submitted to Wolfram Research and I will also update the page when the bug gets fixed.

I emailed/wrote a comment about a bug and you haven’t included it in the list. Why?

Sorry about that – please don’t take it personally.  I am low on time and may not have managed to verify the ‘bug’ or maybe it just didn’t tickle my fancy.  It’s also possible that I simply don’t understand the problem you are referring to and I will not post anything on here that I don’t at least think I understand.  Remember – I’m not trying to keep a list of all Mathematica bugs – just some of the ones that I find interesting.

One of the ‘bugs’ you posted is not a bug – you just misunderstood the situation.

Oops, sorry!  Please educate me so I can update it.

I think I have found a bug in Mathematica – what should I do?

In the first instance I suggest you post it to comp.soft-sys.math.mathematica – there are plenty of people there who know a lot about Mathematica and they (probably) will let you know if you really have found a bug or not. If everyone suspects that it is a bug then your next step is to report it to Wolfram.  Finally, if you think I’d like to know about it then feel free to leave a comment to this post or email me.

FullSimplify bug 1

Clear[n];
FullSimplify[n Exp[-n * 0.], Element[n, Integers]]

expected output:

n

actual output:

n/2

original source – here.

Integrate bug 1

Integrate[k^2 (k^2 - 1)/((k^2 - 1)^2 + x^2)^(3/2), {k, 0, Infinity},Assumptions -> x > 0]

Expected output:

1/2*1/(1+x^2)^(1/4)*EllipticK(1/2*2^(1/2)*(((1+x^2)^(1/2)+1)/(1+x^2)^(1/2))^(1/2))

Actual output:

EllipticK[(2*x)/(-I + x)]/(2*Sqrt[-1 - I*x])

Note that although the integrand is real for all k, Mathematica gives a complex result which is clearly wrong.  Original source – here.

Limit bug 1

Limit[EllipticTheta[3, 0, x], x -> 1, Direction -> 1]

Expected Output:

Infinity

Actual Output:

0

Original Source: here

NetworkFlow bug

The following code should complete in less than a second.

<< "Combinatorica`"
NetworkFlow[CompleteGraph[4, 4], 1, 8]

but in Mathematica 7.0.1 (tested on Windows and Linux) it never completes and hogs a CPU indefinitely. Wolfram are aware of this one and it should be fixed in the next release. Thanks to Gábor Megyesi of Manchester University for sending me this one.

Feel free to let me know of others that you find but please bear in mind the points at the beginning of this post.

  1. November 23rd, 2009 at 18:54
    Reply | Quote | #1

    The first is the most interesting, as you give an inexact (approximate) input, that yields an exact (non-correct) output !

  2. Szabolcs
    November 23rd, 2009 at 21:18
    Reply | Quote | #2

    Integration and taking limits can be complicated, and the validity of some of the steps these functions make during calculations can depend on difficult-to-impossible to test assumptions. So the occasional bug is not that surprising here. The FullSimplify bug is a bit more shocking than these. And here’s one that was really unexpected for me:

    http://groups.google.com/group/comp.soft-sys.math.mathematica/browse_frm/thread/8a43649367ebcc21#

    In the example that was posted, Maximize[] re-seeds the RNG, so it’ll always give the same sequence. That’s nasty.

  3. Szabolcs
    November 23rd, 2009 at 21:25
    Reply | Quote | #3

    I think that the bugs that are really worth mentioning are the surprising ones. An incorrect answer to a symbolic definite integral shouldn’t surprise anyone who has some experience with CASs. But a bug in a function like Sort[] or Tally[] is something really bad simply because it’s unexpected… Mathematica 6 had a nasty Tally bug. (It appeared only when a custom comparison function was used.) It’s fixed in 7.

  4. November 24th, 2009 at 10:44
    Reply | Quote | #4

    @Sander I hadn’t looked at it like that but you are right. It’s all a bit strange.

    @Szabolcs – I agree, the occasional bug in Integrate is not surprising but still worth reporting I feel. They might never get fixed otherwise :) The RandomReal bug is very interesting! Thanks for letting me know abut it!

    Cheers,
    Mike

  5. November 24th, 2009 at 22:32
    Reply | Quote | #5

    @Mike

    Luckily it is correct if you put 0 instead of 0. Who works with inexact numbers anyways ;-) :-)

  6. November 24th, 2009 at 22:38
    Reply | Quote | #6

    Another bug, but was known (according to Rob Raguet-Schofield, Twitter: @ragfield):

    \[Alpha] // TeXForm
    \[Beta] // TeXForm
    (or anything expression for that matter)

    only outputs the last one.
    Same holds for CForm and FortranForm (probably they internally use the same mechanism…)

  7. May 12th, 2010 at 10:13
    Reply | Quote | #7

    While I can see there is an Integrate bug in your “Integrate bug 1″, I’m not sure
    that your “correct expression” (as I read it on 12 May 2010) is “correct”.
    The numbers seem to differ from what one gets from NIntegrate.
    I noted elsewhere that there appear to have been different conventions in Maple and
    Mathematica concerning the EllipticK function.
    (I was asked by SIAM to do a book review, but I don’t think it will be published…)
    http://school.maths.uwa.edu.au/~keady/CAS/siam10keady2.pdf

    I haven’t checked in detail, and I could have made a mistake, or the cut-and-paste
    from the web page into Mathematica might have some subtle error.
    Would like you to check. Thanks

  8. May 15th, 2010 at 20:24
    Reply | Quote | #8

    Hi Grant

    You are correct. I copied the ‘correct expression’ from Maple and from my own testing it appears that you are right concerning the different conventions between the two packages.

    Let’s take x=2 for example. In Mathematica 7.0 I get the result of 0.706094 for the integrand using NIntegrate but my ‘correct expression’ evaluates to 0.799487 at x=2. oops!

    However, if you evaluate the ‘correct expression’ for x=2 in Maple 13 then you get 0.706094 which agrees with Mathematica’s NIntegrate.

    So, the ‘correct expression’ is correct if you use Maple’s definition of EllipticK but it is incorrect if you use Mathematica’s. Furthermore, I need to check my work more carefully in future. It’s still a Mathematica 7 bug for Integrate though :)

    I’ll leave the article as it stands so that the comments make sense in the future. Well spotted and thanks for commenting.

    Cheers,
    Mike

    PS. I also note that I didn’t swap Maple’s EllipticK() to Mathematica’s EllipticK[]. I was clearly having a bad day!

  9. Gabriel
    March 2nd, 2011 at 20:51
    Reply | Quote | #9

    The FullSimplify and the Limit bugs are fixed in 8.0, the Integrate bug now returns the answer unevaluated … after a long time …

    Awesome site by the way!

  10. March 3rd, 2011 at 02:57

    Thanks for the bug fix-report Gabriel and also for your kind comments

Comments are closed.