Somewhere along the line, we all come to trust the numbers that come out of computers. After all, an infallible device told us it was true. So, let us start with a simple example, on a ten digit calculator enter the following:
1E12 + 1 - 1E12
If the 1 is in any position, but the last one, your calculator spits out 0. Despite the fact that the answer is very clearly 1. Using this example, and others, I try to have my students resist the urge to enter numbers into their calculators until the very end of the problem, and they will then usually avoid such problems. Despite my advice to my students, this bit me twice in two days, leading to a corollary to the first rule:
Just because you have a bigger, more sophisticated calculator, does not mean you can trust it!
I use Mathematica daily, and, in some sense, it is my extra large calculator. The first problem I had was the result of this innocuous looking bit of code:
The problem comes in as x goes to 0, n goes to infinity. However, f does not do this, and n times f does not do this either. In other words, f goes to zero faster than n goes to infinity, so that when they are multiplied together the resulting limit is finite. But, I had defined both n and f as functions, so that they are evaluated separately. Therefor when I set x to 0, the whole thing blew up in my face, as Mathematica only saw that I had infinity times something that was finite. I fixed the problem by replacing the function calls with the functions themselves, at which point Mathematica got the hint. Thinking I was done, I ran the code again, and it blew up, again.
This time the trouble came about because of the following term in the denominator:
e[k - q]^2 - 2 e[k - q] e[k - q - qp] + e[k - q - qp]^2 - w[q]^2
Mathematica was saying that at
k = q = qp this term was going to zero. This should not be zero as the first three terms cancel each other out because they equal
(e[k - q] - e[k - q - qp])^2
w[q]^2 is not zero. However, individually each of the first three terms is about 20 orders of magnitude larger than
w[q]^2, so Mathematica was just blithely ignoring it. The solution: ensure Mathematica knows that the first three terms cancel out by using the following, instead.
(e[k - q] - e[k - q - qp])^2 - w[q]^2
It should be noted that increasing the precision of the calculation using either
N[<>,100] or by increasing
$MinPrecision to over 100 does not work. Only the modified form actually gives you a non-zero answer.
So, even with an extra large calculator, you can really foul things up if you are not careful. There are two morals to this story: when performing floating point calculations, order matters, and a careful up front analysis will often help you avoid these problems.
Similarly tagged OmniNerd content: