Making Embedded Systems

Chapter 9. Math

When we looked at trading resources in the last chapter, you had to choose between RAM, code space, and processing cycles. Trading resources goes only so far. Sometimes you need to make your code go faster. Not knowing what you’ll need for your system, I can still guess that you’ll need to implement some math (because that is where processors excel).

The less your system does, the fewer resources it needs to do them. Sometimes we confuse accuracy, which is important, with precision, which can go too far (see ). If you can quantify the range of data you expect and your error budget, there are some useful methods to reduce unnecessary precision for all sorts of algorithms, thereby saving RAM and processing cycles.

Accuracy Versus Precision

Accuracy is a measure of how correct you are. Precision is how many digits you show in your answer. Both have degrees to them; one answer can be more accurate and/or more precise than another. A really accurate answer knows its limitations. For example, what is the mass of an electron?

Mass of an electron	Is it precise?	Is it accurate?
12.12345124 kg	Stupidly so	No
10–30 kg	No	Far more so than 12 kg, and accurate enough for most conversations
9.109 x 10–31 kg	Yes	Even more so
9.1090000001 x 10–31 kg	Uselessly so	Same accuracy as the previous answer
(9.1092 +/– 0.0002) x 10–31 kg	Yes	Yes, best answer yet

Precision can be noise. If the extra bits of precision don’t mean anything, they can needlessly complicate your system, use precious RAM, and waste processor ...