Computational Thinking: Pattern Recognition • Jonathan Cook

This page builds on our introduction to computational thinking. Recall our five foundations of computational thinking:

Pattern Recognition

When programming computers (telling them what to do), we are trying to automate something that we used to do apart from computers. Almost always our desire to do this comes from a feeling of, “Why am I wasting my time doing this over and over when a device can do it for me?!?”

That feeling comes from the fact that we have recognized a pattern to what we are doing. This is really the first step in getting a computer to do something for us.

The next sections give short descriptions on specific kinds of patterns and how we think about and use them:

repetition: This happens repeatedly, based on these constraints
How do separate steps fit together, and do they need to be ordered?
When this happens, that should follow; or if this condition is true, then this action should occur, or else that action should occur
What similarities or regularities show up in the data, and how can they be exploited for better computing?

Pattern 1: Repetition

Probably the easiest pattern to recognize is repetition: we have something that we do over and over and it would be great to automate it. Lots of real devices are based on the same idea. We have a blender in our kitchen to replace going round and round a bowl with a spoon or a fork or a whisk. We have a compressor to fill up a tire instead of repeatedly pumping an air pump manually. Even a scooter replaces the repetition of putting one foot in front of the other (although walking is good for you!).

One problem in this pattern is recognizing what it is that is repeating! In the LightBot game, part of solving a level is seeing what pattern of actions should repeat.

Patterns that are very simple repetitions are easy to program, but often there is some conditional behavior we have to add in to the repetition, based on the data we are repeating over. Perhaps we only want count the number of customers with an outstanding unpaid balance: we have to do a repetition over our customers but then only increment a counter when we are looking at one with an unpaid balance, and skip others.

We also have to know how to stop the repetition. Sounds simple? It usually is, but a common early programming mistake is an infinite loop: a repetition that never stops. These are the bane of new programmers!

Pattern 2: Sequencing and Ordering

Computers are pretty simple devices, so we have to break down our recognized behavior patterns into simple steps, and then we need to figure out how these should get sequenced, or ordered.

Usually it is very obvious, but not always. How often in real life do you get ahead of yourself? You get the cereal out to pour a bowl but forgot to get a bowl out – no big deal but you usually get the bowl first and so you say “Doh!”. Beginning programmers often write code and get ahead of themselves, putting steps out of order that need to be in order.

A more advanced version of this is noticing when steps can be in any order: that is, they can happen in parallel with each other! This is the beginning of taking advantage of the multi-core CPUs that all of our devices have.

Pattern 3: Consistent Condition-then-Action

There are two forms of condition-action to pay attention to.

The first is within some computation. We have already said that repetitive tasks often have some conditional behavior in them. This is one place where we must pay close attention to what conditions our code encounters in the data and how it affects the resulting actions.

What technology we are using can affect how this looks in our software, but the need to understand the condition-action is still the same. If we have, say, a customer list within our running program and want to only process those with outstanding balances, we will probably write code to repeat over the list, and then apply the action only when the current customer we are looking at matches our condition.

But if our customer data is in a database that uses SQL to fetch data, we will probably write a database query that selects only those customer records that have outstanding balances; in this case we do not need to re-check the condition in our program because we know the customer list we got from the database query already matches our condition!

The second form is where the condition is an event, which drives our program to respond with an action. Event-oriented programming is harder because you don’t really have a “whole” program but rather pieces of code that are actions in response to events, and you have to conceptualize how those pieces act together to make everything work.

Modern phone/tablet apps, window-based GUI applications, and others are all event-driven programs, and when you create them you must follow this model. Your program is not in control! Rather, it just waits for events.

Pattern 5: Exploiting Regularities in Data

The patterns above are focused on computation, but patterns occur in data, too.

If my data is naturally clustered or grouped, I may be able to generalize it to the group level, naming each group and giving it the shared attributes, and only record, for individual items, the data needing unique values. Simplifying data, without going too simple, is an ongoing challenge in computer science.

If my data has natural connections within it that form a tree, I can take advantage of lots of programming solutions for tree-based data. There are lots of other special connecting patterns that computer science has worked hard to make efficient algorithms for, but trees (and simple lists) are the best.

Patterns can also be designed into our data sometimes. For example, the binary values used for alphanumeric characters and symbols, known in the US as ASCII and extended for general Latin characters as ISO 8859-1 are purposely chosen so that lowercase and uppercase letters differ by only 1 bit. The numerical digits ‘0’-‘9’ are also chosen so that the lower four bits are their actual numerical value.

Ideal Pattern Goal: Generalization

One aspect of pattern recognition is figuring out how the pattern both generalizes and specializes. Thinking about the most general case possible allows us to define a pattern that is useful over the most possible things. But then we need to know how exactly to make it specific for each thing; this involves parameterization.

In programming, when we create functions (or methods), we almost always have to give them parameters (also called arguments) so that they can specialize their code for each particular use.

A Complication: Exceptions

Finally, it is common to have some things be so different that they need to be exceptions to the pattern; we like to avoid exceptions but sometimes it is impossible. We often don’t realize many of these exceptions until customers start using our product; then they complain and we need to modify our code so that it correctly handles the special case that they uncovered.

Sometimes exceptions are well known but still cause many problems. The Earth’s solar revolution is unfortunately just about 365.25 days, which we solve by designating a leap year every four years – almost; the actual calculation is more complex. This has been the source of many bugs, some of them quite serious.

Exercise Questions

To work on using using pattern recognition, consider the following exercise questions. You can do these over and over with many different ideas.

Pick either a) an activity that you want to automate, or b) some information you need to use in some activity.
Start describing this to your friend. Or, start writing down a description of it to yourself – just “thinking in your mind” is not enough, you should either be speaking it out loud or writing it down. A physical reality is needed.
As you do (2), or after you are done with 2, look for, discuss, and ask about patterns you see in what you have described. Then ask yourself: How can this pattern be used in my automated solution or in my software? Or, at least, write down the patterns that you see so that you don’t forget them and may be able to use them in the future.