How to Debug: Elementary Introduction to the Wolfram Language

47	Debugging Your Code

Even the most experienced programmers have to spend time debugging their code. It’s an inevitable part of programming. But in the Wolfram Language it’s particularly easy, especially if you follow a few principles.

The first and most important principle is to try out any piece of code you write. Because the Wolfram Language is interactive—and symbolic—you can always instantly do this. So even if you just make a tiny change, run your code again, and see if your test examples still work. If they don’t, fix the code before you go on.

The Wolfram Language can sometimes tell as soon as you type something in that it’s likely to be wrong—and then it’ll color it red.

A piece of code with various problems, indicated with red:

Once you run a piece of code, the Wolfram Language can also often tell if things have gone obviously wrong—in which case it’ll display a message. The code here ends up, for example, asking for the first element of a length-0 list.

Something is obviously wrong when First is applied to the {} that’s produced by Cases:

In[1]:=

Out[1]=

Sometimes the Wolfram Language may not know what to do with something, but it may not be sure there’s a problem. In such cases, it’ll just leave the input unchanged and return it in a symbolic form that can later get a definite value.

Without values for a, b and c, the Wolfram Language just returns this unchanged:

In[2]:=

Out[2]=

If you generate graphics with symbolic pieces that can’t be rendered, you’ll get a pink box:

In[3]:=

Out[3]=

As you build up functions, it’s quite common to have fragments of code that you want to test without finishing the function. You can do this by setting values of variables using With—which works like Module, except it doesn’t allow values to be reset.

Use With to temporarily set m=4 to test a fragment of code:

In[4]:=

Out[4]=

When debugging takes a long time it’s usually because one’s made the wrong assumption about what one’s code is doing. And in my experience, the best way to overcome this is just to systematically analyze how the code behaves, making tables of results, generating visualizations, testing out assertions and so on.

Make plots to see what the code is doing:

In[5]:=

Out[5]=

If this code is working correctly, the result should contain every number from 0 to 2 ^m-1:

In[6]:=

Out[6]=

Systematically check this up to m=10:

In[7]:=

Out[7]=

Sometimes it’s not sufficient just to see the final result of a piece of code; you need to see what’s going on inside as well. You can insert the function Echo anywhere to print intermediate results or values from your code.

Echo prints values, but does not interfere with the result:

In[8]:=

Out[8]=

If you’re running a long computation, you can monitor its progress using Monitor.

Continuously show (with a frame) the value of n reached so far:

In[9]:=

Out[9]=

Echo and Monitor just display things. If you want to actually capture intermediate results, you can do it using Sow and Reap.

Reap gives the final result together with a list of everything that was sown by Sow:

In[10]:=

Out[10]=

This sows successive values of Length[#], and reaps the results:

In[11]:=

Out[11]=

Vocabulary

With[{x=value},expr]		compute expr with x replaced by value
Echo[expr]		display and return the value of expr
Monitor[expr,obj]		continually display obj during a computation
Sow[expr]		sow the value of expr for subsequent reaping
Reap[expr]		collect values sowed while expr is being computed