I was recently asked by a friend who is tutoring a young student if I could provide an explanation of why they needed to study math in school.
I think a lot of people would ask the question, “why do I need to learn math?”. And for most people, the answer is, they don’t. Other than the need to balance their checkbook or make change, there’s not much call for math in daily life.
However, one thing that math gives us is the ability to operate in the world with precision. If I ask you to go to the grocery store and bring back a dozen eggs and 3 pounds of sugar, and you come back with 11 eggs and 3 1/2 pounds of sugar, it’s no big deal. But if I’m a doctor formulating a dose of a cancer drug, an engineer designing a support beam for a bridge, or a scientist measuring the light from a distant star, it’s really important to get the numbers right. As our technology advances and our society grows more complex, it becomes more and more important to be able to understand how to manipulate our environment in ways that are accurate and precise.
I always had difficulty learning math, even to this day after working as a programmer for 45 years. In particular, I always had a hard time understanding an abstract math concept until I actually needed to use it. However, I’ve been forced into learning a lot of math because my work required it, both as a computer game developer and as a software engineer in general.
My earliest example of this came when I was in high school, back in 1975. In my math class, I struggled with trigonometry: sines and cosines. “This is so dumb”, I thought. “What’s the point of this? Who thought this up?” But then I tried to write a “Star Trek” game on the school computer — one that would print out the map of the galaxy on the teletype, using asterisks and pound signs to represent stars and planets. At one point, I needed a way to calculate the angle to fire the photon torpedo so as to hit the Klingon ship. All of a sudden, it made sense — sines and cosines! So that’s what it’s for!
I had similar problems with logarithms: they didn’t make any sense. But a few years later, I was working on a music program (Music-X) and I needed a way to calculate the frequency of a musical note for a given key on the piano keyboard. As you may know, a piano has 88 keys arranged into 7 “octaves”, where each octave has 12 keys (counting both black and white keys). Each octave is exactly twice the frequency of the previous octave: so the ‘A’ key on the middle of the keyboard has a frequency of 220 Hz (220 cycles per second). The next ‘A’ key above that has twice that frequency, 440 Hz, the one above that 880 Hz, while the ‘A’ key just below the middle octave has a frequency of 110 Hz.
(Historical note: this doubling of octaves effect was discovered by none other than Pythagoras, all the way back in Ancient Greece. Only in his case, he used lute strings of various lengths.)
Let’s assign a number to each key: the lowest key on the keyboard will be key 0, and the highest will be 87. We can then write a formula that takes as input the key number and gives us the frequency:
frequency = base_frequency * pow(2, key / 12)Where:
- key is the piano key number, starting from 0
- base_frequency is the frequency of key 0
pow()is a function that raises a number to a power.
So in English, this is taking the key number, dividing it by twelve, and then raising 2 to the power of that number. Dividing the key number by twelve gives us the octave, 0 through 7. Raising 2 to the power of the octave gives us the doubling we want: 1 for octave 0, 2 for octave 1, 4 for octave 2, 8, 16, 32 and so on. Finally we multiply by a base frequency value to get the actual frequency.
What happens if the division doesn’t come out evenly? For example, suppose we choose middle ‘C’ instead of middle ‘A’. Counting both black and white keys, C is 3 keys above ‘A’, so when we divide by 12 it will be 3/12ths greater than the number for ‘A’. However, this is perfectly fine: it means that instead of raising 2 to the power of 4 (assuming middle A is in the 4th octave) giving a value of 16, we’ll raise 2 to the power 4 and 3/12ths, giving us 19.027. Multiplying that by our base frequency gives us a result of 261.626 Hz, which is exactly the frequency of middle C.
What about going in the other direction? That is, given a frequency, can we calculate which piano key produces that frequency? All we have to do is run the equation in reverse. But what’s the reverse of taking a number to a power? You guessed it: logarithms. Specifically, in this case we need to take a “base 2 logarithm” which is typically spelled log2():
key = 12 * log2(frequency / base_frequency)I later discovered that logarithms and exponents are everywhere in music. For example, when performing an “accelerando” — that is, a section of music where the tempo is slowly increasing, going faster and faster — you don’t want to increase the tempo by the same amount each measure, but instead by a multiplicative factor, kind of like compound interest in finance: for each measure, the beat gets 10% faster from the previous measure. So the relation between seconds and beats can be described by an exponential / logarithmic relationship.
My work as a computer game developer has also required me to learn a lot of math. 3D graphics is all about math: vectors, matrices, trigonometry, curves and so on. Simulating game physics requires a thorough understanding of calculus: integration, differentiation, differential equations as key.
My most recent work involves working with color — I created a library for working with colors in the Bevy game engine, a popular open-source framework for making games. This includes ways to manipulate colors, such as lightening, darkening, mixing colors together in various proportions, converting between different representations and so on.
Working with color requires a lot of subtle math, due to the fact that human eyes are not linear, nor are computer monitors. What do I mean by “not linear”? Well, the individual display elements on a computer monitor are driven by electrical current: decreasing the input voltage produces a dimmer light, while increasing the voltage produces a brighter light. If the display were “linear”, then increasing the voltage by a factor of 2 would increase the brightness by a factor of 2 as well. But it turns out this is not the case: the relationship between voltage and brightness is actually an exponential function, similar to the musical note function mentioned earlier.
This is important because when we are drawing a 3D scene we need to calculate the amount of light falling on each object. For example, if a table is lit by sunlight, but also lit by a lantern or a candle, we need to calculate the total amount of light striking the tabletop by adding together the amount of incoming light from each light source. This calculation happens in “linear color space”, meaning that we can add the light levels together using simple addition and multiplication. However, when we want to display the resulting image on the screen, we need to convert all the generated pixels from linear color space into the color space of the computer monitor, which is non-linear. If we don’t do this, the image looks wrong — dark and contrasty.
Anyway, I hope these examples illustrate some of the benefits of learning math for an engineer.
