Debugging DSP code.

• Software Development
• Signal Processing
• Debugging

I am fascinated with neural network processing and have been playing with them since the 80's.

I am a frequent contributor to the Numenta forum. Numenta is the current project of Jeff Hawins, the guy that gave us the Palm Pilot. They are working with the HTM model. This is a system based on studies of the functions of the cortical column and has some very interesting properties: It processes sequential data streams and has very effective one shot learning. The data is arranged in Sparse Distributed Representations. This does not work at all like the usual deep learning layered networks and operates in completely different problem spaces. If you do work with sequential data this is a pleasant alternative to RNNs.

The forum is here:

https://discourse.numenta.org/

But that is not my focus today. One of our users was getting some strange output from the model he was running and I looked at his output graph and noticed a pattern to the error. Many times in debugging DSP code I have noticed that the errors have a pattern that ties back to certain types of programming errors. I offered this up in the forum and it occurred to me that many of the users of ER may do the same type of programming.

Here is the original posted problem:

https://discourse.numenta.org/t/asymmetric-confide...

The gold value is supposed to be a confidence score after training on this sine wave. After training this should be a very high value. The error is both large AND it seems to be varying with the input.

and this is what I posed in response.

We see stuff like this when doing integer math on MPUs. I don’t know the code and am totally uninterested in digging through OOP crap but this problem looks strangely familiar.

Problems with signed vs absolute values come to mind. Where this gets to be a real problem is comparisons.
Another common and related problem is shifting frames of reference during calculations. IE: picking the wrong intermediate value for further calculations.

Two other perennial problems are:

a) getting scaling wrong. Note that the error seems to vary with the absolute value of the sine wave. If the calculation was using this input to establish scaling of the value the error would look something like what is shown.

b) This is based on a time varying value; using the “before” in one part of the calculation and the “after” in a different part can be maddeningly difficult to find. This is an insidious version of the wrong frame problem.

Adding two cents that probably do NOT apply to this problem.
Picking the wrong stride for the measurement can produce “chunky” calculations. The delta between readings is the dT and dV part of your slope calculation. If this is either aliasing with the samples taken of the raw data (unlikely in this case) or too small for the representation (integer math) can be problems - you are reading so fast that the change between samples is too small to process effectively.

All you fellow programmers - what kinds battles have you fought with wonky code? What errors have you wrestled to the ground and defeated? How did you find them? Which ones keep sneaking back into your code?

Sign in