Recently I did some numerical experiments in Mathematica involving the hypergeometric function . The results were clearly wrong (a positive-definite matrix having negative eigenvalues, for example), so I spent a couple of hours checking the code. Finally, I discovered a bug, but it was not in my program!

This post is not about the hypergeometric function, it is enough to know that it accepts four arguments, usually typed as . For some parameters , , it reduces to elementary functions, for example . Of course, Wolfram Research products are aware of that (link). A sligth modification of the parameters of the hypergeometric function does not change the value of the function significantly, it is smooth in all four arguments. But according to Wolfram Alpha, is not even continuous! Click on an image to see the plot at the Wolfram Alpha site.

There is clearly something wrong with the way Wolfram Alpha (and its kernel, Mathematica) computes . This issue is related to finite precision calculations: forcing Mathematica to work with higher precision helps a lot, but it does not resolve the problem completely. Numerical instability is nothing spectacular, it is a common issue in approximate computations. Here, however, the error cannot be explained simply by accumulation of numerical errors, the result is just completely wrong: zero instead of somethign close to 0.8. This kind of bug is quite unexpected in such an advanced application.

Let us play around this bug for a while. Wolfram Alpha asked about , answers correctly (link). The numerical approximation (N[…]) is “result: 0.81072238…”, which is fine; the next line, however, reads “number name: zero” (link). Things get even worse if we request five digits only: “decimal approximation: 0.810722, result: 0.0” (link).

I was in fact quite lucky to find this issue: there are not too many parameters for which is not computed accurately. In the contour plot of they are all concentrated near the line , when is close to . And this is exactly the case I was interested in.

Nearly a week ago, I submitted this bug to Wolfram Support Center. Unfortunately, apart from an automated confirmation letter (claiming that they typically answer within three business days), I have received no reply.

The above bug might be caused by Mathematica using a wrong hypergeometric identity (perhaps this one?) in numerical evaluation. If this is the case, it will be rather easy to fix. Until then, one can simply use another hypergeometric relation (like this one) explicitly. For an example, see the last two (theoretically identical) plots on the right.

Let me end this post with a few words about what I was trying to do when I discovered this bug. Unfortunately, this will be a little bit technical for those not used to non-local operators and jump processes.

Let be an open set in . Consider a Brownian motion (with variance ) starting at a fixed point , and let denote the (random) first time when hits the complement of . The mean amount of time that spent in a Borel set before can be expressed as for some function . It can be proved that is the Green function for , the Laplace operator in with zero Dirichlet boundary conditions. In fact, this is probably the easiest way to construct the Green function for a general open set.

Replace in the above paragraph the Brownian motion with the isotropic -stable Lévy process (here ), and will become the Green function for the fractional power of the Laplace operator , with zero exterior condition (this is no longer a local operator, so instead of *boundary* conditions, one must give *exterior* condition). This operator is usually denoted as , and it is important to note that this is something else than . Fractional powers of are inverse operators to Riesz potentials, and they are important examples of pseudo-differential operators. It is not my point to give a detailed introduction to probabilistic potential theory and Riesz potential theory herem and there is much literature on these topics, inlcuding classical textbooks by Landkoff, Bliedtner and Hansen, and Blumenthal and Getoor.

If is a ball, then the formula for the Green function for is relatively easy to find using Kelvin transform. Suprisingly, similar method works for , due to the calculation of M. Riesz in 1938, in this case the formula for the Green function for a ball is:

While I was working on numerical bounds for the eigenvalues of for (that is, a one-dimensional ball), I needed to compute an array of values of . Numerical approximation to the integral worked fine, but it was very slow. For that reason, I tried the formula with the hypergeometric function. It worked much faster, but the results were different (and plainly wrong). While I was checking the code, I plotted the graph of for . The correct picture should be like the one below (prepared using a better hypergeometric identity).

Instead, Mathematica produced the following image.

The erroneous plot can be reproduced in lower resolution using Wolfram Alpha (link).

I will update this post as soon as Wolfram contacts me.

*Update, Mar 11, 2011:*

I have just received a copy of Mathematica 8 and istalled it on my computer. The first thing I checked was, clearly, whether Wolfram fixed the hypergeometric bug. And they did! A huge surprise to me, as they did not respond to any of my two bug submissions. And the bug is still present on Wolfram Alpha! Does Wolfram Alpha run an older version of Mathematica then?

*Update, Mar 23, 2011:*

I have just received a kind email from Wolfram Research confirming that the issue has been resolved in Mathematica 8.

by this way, is it posible to receive a free-copy of Mathematica8? he.he

Well, there is a 15-day trial:

http://www.wolfram.com/mathematica/trial/

Some institutions have multi-user license, why don’t you check if your university has one?