Well then, here is (considerably) more detail. I'll first remark that this is only my own take on the issues and events, and does not necessarily reflect or represent the views of Wolfram Research.
The main focus of the article was on certain problematic matrix determinant computations. The authors were, understandably, unhappy with the erroneous results they were getting. Suffice it to say that we were too. With the recent release of version 10.0.2 we now, happily, have it fixed. But the concerns run deeper than simply "here is this bug". So I'll address in more detail some of the specific issues raised in that article, and provide a current status report.
Here is some background history. First I should mention that the authors have been in contact with us about this integer determinant problem. They initially alerted us to an example in October 2013, roughly a year before publication of the article. In that instance the erroneous integer matrix determinant was tracked to a simple typo (it happens), and fixed. The repair appeared in Mathematica 10.0.0, released July of this year (that was, to the best of my knowledge, the first release following our becoming aware of the issue).
That should have been the end of the story. So what happened? In this instance we had a superficial problem hiding a deeper one. The latter simply did not manifest itself in the example we first saw. We became aware of this second problem only in August of this year, when the authors let us know there were examples that still gave erroneous results in a somewhat random manner.
As it happens, at the time we learned of this we were nearing the end of a test-and-fix cycle prior to releasing version 10.0.1. Again the bug was found and repaired (well, actually squashed into bug juice, to give the technical description). This fix and numerous others have been released quite recently in version 10.0.2.
The fact that the article appeared before the repair is perhaps unfortunate for us, but that's life. What I take to be the main point of the article remains every bit as important as before: sophisticated mathematical software uses some intricate algorithms, and one should be aware of the potential for erroneous results. That this problem appeared only in version 9 is in fact due to our frequent adaptation of cutting edge methods: earlier versions used a more pedestrian method that was not prone to this particular issue. Not surprisingly, the computations in question were also generally slower.
As one who has often delved into code for symbolic integration I will also comment on the three examples from that area that also were noted in the article. I'll start with a possibly controversial remark. I hold the opinion the three errant integrals do not comprise not terribly serious bugs. Improvements, to be described below, have been made. But the lower severity level should help to explain why these did not show up in version 10.0.2: they simply have nowhere near the priority of the determinant problem, and there are risks to "fixes" that have not had time for thorough testing and assimilation.
So let us have a look at these examples. The first concerns this integral.
Integrate[Sqrt[(2 t)^2 + (4 - 3 t^2)^2], {t, 0, 2}]
The result given is simply wrong. What happens is we calculate the antiderivative (indefinite integral) and try to determine if there are singularities on the path of integration. We find none, evaluate at the endpoints a la the Newton-Leibniz method, and give a (numerically incorrect) result. Why do we miss the path singularities? A rough explanation is that it is borderline hopeless to find these when elliptic functions with complicated innards are involved.
By the time the article appeared we had already made this example instead return unevaluated; that happened in response to a different but related bug report. This change is deemed a relatively minor one and was not ported to version 10.0.2. (When will it appear? More on that presently.) I will remark that this change comes at a cost: we lose closely related integrals that were done just fine when the path did not include singularities. In this case the singularity is larger than 1. So integrating from 0 to 1 was working correctly and yet, in the version currently under development, it is unevaluated.
Here is the second integral.
In[473]:= Integrate[Exp[-p*t]*(Sinh[t])^3, {t, 0, Infinity}]
Out[473]= ConditionalExpression[6/(9 - 10 p^2 + p^4), 0 < Re[p] < 1 && Im[p] == 0]
The authors point out that this is flat-out wrong. The correct result requires that p be real valued and larger than 3. When I first read the article, my reaction was that, of the three integrals, certainly this one should be handled better (the other two posing more serious difficulties). Further analysis showed that the error was due to a simple bug in the code that does the asymptotic analysis. The version in development gives instead the correct conditions: ConditionalExpression[6/(9 - 10*p^2 + p^4), Re[p] > 3 && Im[p] == 0]
The third integral in the article, shown below, incorrectly gives a result of zero.
In[474]:= Integrate[Integrate[Abs[Exp[2*Pi*I*x] + Exp[2*Pi*I*y]], {x, 0, 1}], {y, 0, 1}]
When there is an explicit iterated integral, I generally find it better to put it into the form of a multiple integral, as below.
In[475]:= Integrate[Abs[Exp[2*Pi*I*x] + Exp[2*Pi*I*y]], {x, 0, 1}, {y, 0, 1}]
In[513]:= Integrate[Integrate[Abs[Exp[2*Pi*I*x] + Exp[2*Pi*I*y]], {x, 0, 1},
Assumptions -> 0 <= y <= 1], {y, 0, 1}]
Out[513]= 4/\[Pi]
Here is my take. The original formulation of this integral goes astray early on, due to a problematic combination of a symbolic parameter, complex values in intermediate computations, and a nonanalytic function (Abs in this case) whose path singularities are difficult to pin down absent knowledge of that parameter. In the development version there have been improvements to this family of integrals although the hardest issue, in this single inner integral, remains.
So when will the these improvements appear? A more subtle question, one often not recognized, is this: Will these be released at all? Whenever changes go into the product there is the potential of a ripple effect. For example, disabling the elliptic integral in that first example could conceivably have a deleterious effect on exact computations involving regions, or probabilities, or... It will take some time, and the ministrations of the QA group, before we decide whether it is preferable to lose working examples or return unevaluated. I am fairly confident that the change resulting in the better outcome for that second integral will survive testing. So that at least should emerge in a future release. The variant of the third example that was addressed falls somewhere in the middle, in terms of risk vs. reward (of the fix). I am cautiously optimistic that it too will not cause damage downstream, and will appear in a future release. But such optimism is never a guarantee, and long experience with definite integration teaches that one should temper one's expectations in this area.
I hope this gives some idea of how we view the specific problems raised in the article, and also some idea of how we triage and address erroneous results in general.
