Physicists have got a great sense of humor when it comes to software bugs. A “bug” is simply something which stops the software from running when we want it to continue. When a bug is known, but seemingly unavoidable, it can be called a “feature”, in an attempt to make it sound a little less ominous. There’s usually a little chuckle in a meeting when someone announces that there’s “an interesting feature in this code”. When I discovered the terminology behind the quantum bug I was almost in hysterics. Here’s a selection of them:
Heisenbug
Hey you! Get out of my code!
Named after the Heisenberg uncertainty principle, this kind of bug disappears when you try to study it! The Heisenberg uncertainty principle usually reads \(\Delta p_x \Delta x \ge \hbar /2\), where \(\Delta p_x\) is the uncertainty in the momentum (in the \(x\) direction, say) and \(\Delta x\) is the uncertainty in the \(x\) position. When we know one of these quantities with a given precision, we lose precision in the other quantity. For a Heisenbug we have:
\[
\Delta K_c \Delta K_b \ge I
\]
This time \(\Delta K_c\) is the uncertainty in our knowledge of the conditions that caused the bug, and \(\Delta K_b\) is the uncertainty in our knowledge of the behavior of the bug, and \(I\) is some (unknown) amount of information we can get about the bug. So we know what caused the bug, we turn on the debugger, or try to get some other information about the bug to try to “catch it in in the act”, and in doing so we lose information about what caused the bug, and the bug disappears! Weird stuff!
Schroedingbug
This kind of bug is usually found in code that never gets executed. When it does get executed the outcome is unpredictable. For example, think about this:
if(a<0 && a>0) {
a = a/b ;
}
Since a cannot be both negative and positive, the code inside the curly braces would never get executed. Some clever programmer comes along and changes things:
if(a<0 || a>0) {
a = a/b ;
}
Now the code executes if a is positive or negative (ie not zero.) But in fixing this line of code the programmer has introduced another bug. When happen when b is zero? The programmer has introduced a Shroedinbug, with a wavefunction:
\[
\psi_{code} = P(b \ne 0)\psi_{succeed} + P(b=0)\psi_{fail}
\]
Good luck to whoever has to debug that!
Cosmic bug
Also know known as the alpha particle bug, this happens when a small part of the data set used is corrupt in some way. In a lot of cases this would be the same as having normal data, and then a cosmic ray comes in from space, hits a part of the memory or hard disk, and some 1s and 0s get all messed up, leading to corrupt data. Finding these bugs is usually quite easy, but it can also be frustrating. After all, your code can run perfectly fine for several hours, processing millions of events, only to have it fail in a single event. Wishing away corrupt data is just like wishing away cosmic rays. It can’t be done. And very often, nobody knows where they come from.
Bonus material: How to use the cosmic bug your advantage!
Fermi gas bug
Okay, I made this name up and it just a fancy word for “memory leak”, but it goes hand in hand with the cosmic bug. Suppose you think you have a cosmic bug and you suspect that event number 24601 is corrupt. How do you test this? Well you exclude the first 24600 events and take a closer look at what is happening. (This just skips about 24,000 events, saving you lots of time.) Everything works fine until you get to about event 50,000, then things crash again. So you start from event 50,000, and find that things are okay until you get to event 75,000. It seems that these three events are simultaneously cosmic events and not cosmic events! In fact, it’s a Fermi gas bug. The software uses more and more memory until eventually it runs out of memory and crashes. That’s a bit like how electrons act in a Fermi gas. You can only fit so many electrons in to the available states, and the bits of memory act like electrons. Once you’ve filled the states, you’re out of luck!
Mandelbug
The original Mandelbug?
Named after Benoit B Mandelbrot, this kind of bug is very very complicated. (By the way, the B in Benoit B Mandelbrot stands for Benoit B Mandelbrot…) The conditions that cause the bug are so amazingly complicated that they’re almost impossible to reproduce, and may even be chaotic. Even worse, they can be the product of lots of other much smaller bugs. The conditions are still deterministic, but good luck reproducing them! It’s a bit like making a fractal or predicting the weather. The answer is out there, but until you let the system go through the motions you never know what the outcome will be. Failed fits are a great example of this kind of bug. Changing the initial values of the parameters by a tiny amount can be the difference between success and failure.
Bohr bug
A Bohr bug is the simplest bug of all. Just like the semiclassical quantum mechanics of the early 20th century, the Bohr bug is in a definite state and you can measure all of its properties. These come up all the time and usually easy to spot and fix. But just like in physics, we’d be fooling ourselves if we thought that everything was this simple.
Generic quantum bug
So what was my bug? Well it didn’t seem to fit into any of these categories. Using the same conditions sometimes it would work and sometimes it wouldn’t. If I had to write a wavefunction for it might look something like this:
\[
\psi_{code} = a\psi_{succeed} + b\psi_{fail}
\]
Unfortunately I don’t know the size of \(a\) or \(b\)! So I’d better work out how to fix this.
I suppose we could add a few more bugs to the list:
Bose bug
Like two bosons occupying one state, two variables can use the same memory (for example, two pointers to the same object). When the state of one changes, so does the state of the other! Hours of hilarious debugging!
Quantum tunnel bug
Suppose you declare an unsigned int (a positive integer) and assign it a negative value. What happens? Well usually you get a huge positive number instead. The value of the variable tunneled from 0 (a sensible value) to 4294967295, which is unphysically huge!
Nuclear chain reaction bug
Suppose you have a bug, which causes two more (identical) bugs, which cause four more identical bugs… You’ve got a chain reaction which isn’t going to end any time soon! We all have these from time to time and they can be nearly impossible to see in advance. For example, let’s say you apply a weight of 0 to a sample. Anything weight that gets multiplied by this weight will also be 0. Hours later you find your code worked and you got an output. But everything is 0.
Any more suggestions? Leave them in the comments!
