For the last week or so I have been working on an update to Think DSP. The latest version is available now from Green Tea Press. Here are some of the changes I made:
Running on Colab
All notebooks now run on Colab. Judging by my inbox, many readers find it challenging to download and run the code. Running on Colab is a lot easier.
No more thinkplot
For the first edition, I used a module called
thinkplot that provides functions that make it easier to use Matplotlib. It also overrides some of the default options.
But since I wrote the first edition, Matplotlib has improved substantially. I found I was able to eliminate
thinkplot with minimal changes. As a result, the code is simpler and the figures look better.
Still using thinkdsp
I provide a module called
thinkdsp that contains classes and functions used throughout the book. I think this module is good for learners. It lets me hide details that would otherwise be distracting. It lets me present some topics “top-down”, meaning that we learn how to use some features before we know how they work.
And when you learn the API provided by
thinkdsp, you are also learning about DSP. For example,
thinkdsp provides classes called Signal, Wave, and Spectrum.
A Signal represents a continuous function; a Wave represents a sequence of discrete samples. So Signal provides make_wave, but Wave does not provide make_signal. When you use this API, you understand implicitly that this is a one-way operation: you can sample a Signal to get a Wave, but you cannot recover a Signal from a Wave.
On the other hand, you can convert from Wave to Spectrum and from Spectrum to Wave, which implies (correctly) that they are equivalent representations of the same information. Given one, you can compute the other.
I realize that not everyone loves it when a book uses a custom library like
thinkdsp. When people don’t like Think DSP, this is the most common reason. But looking at
thinkdsp with fresh eyes, I am doubling down; I still think it’s a good way to learn.
Nevertheless, I found a few opportunities to simplify the code, and in particular to make it less object-oriented. I generally like OOP, but I acknowledge that there are drawbacks. One of the biggest is that it can be hard to keep an inheritance hierarchy in your head and easy to lose track of what classes provide which methods.
I still think the template pattern is a good way to present a framework: the parent class provides the framework and child classes fill in the details.
However, based on feedback from readers, I have come to realize that object-oriented programming is not as universally known and loved as I assumed.
In several places I found that I could eliminate object-oriented features and simplify the code without losing explanatory power.
Pretty, pretty good
Coming back to this book after some time, I think it’s pretty good. If you are interested in digital signal processing, I think the computation-first approach is a good way to get started. And if you are not interested in digital signal processing, maybe I can change your mind!
Here are the links again: