The CT Cycle

16 April 2022

Now that we have established what computation is and how it can be used as a framework for thinking, this layer will attempt to demonstrate CT in practice. To do that we need to discuss algorithms. CT is distinct from all other theoretical frameworks in that it is oriented toward solving problems through algorithmic solutions. Many computer scientists believe their discipline should really be called algorithm science because this concept is so fundamental to what they do. I wrote a pamphlet a while back that explained what an algorithm is in non-technical terms. I will begin this section by reprinting that lay-person's description first and then move onto a technical description.

Non-Technical Description of an Algorithm 

An algorithm is a set of rules that helps a person make a decision. It can easily be understood through a non-digital example. Imagine you are at the library deciding which book to read next. You recently enjoyed a horror novel by Stephen King, so you decide to check out another King novel. This time, however, you read The Green Mile, one of King’s novels in a genre other than horror. You discover it is not to your taste, so you refine the criteria by which you choose your next book, according to the stipulation “a novel written by Stephen King in the horror genre.” This feedback loop continually narrows the range of options available to you every time you go to the library, making it easier to select a book with each new piece of information. However, though Stephen King is a prolific writer, the total number of novels he has authored is still quite small as a data-set. Determining which of his 61 novels to read is a difficult decision but it is still a decision that has only 61 alternatives. In situations where we must decide between a number of alternatives that is greater than what we can possibly compute on our own, we often turn to an algorithm that amplifies certain alternatives based on factors outside of our own experientially derived preferences.

For example, if you have read all of King’s novels and you decide to expand the data-set in order to increase the number of novels available to you, you can ask a librarian to recommend some books that are similar to King’s. That would be a form of content amplification because the librarian would introduce selection criteria outside of your own experiences that bias particular alternatives. A librarian with a cursory understanding of genre fiction may be able to point you to authors like Dean Koontz or Anne Rice, whereas a librarian who happens to be a horror aficionado will have an algorithm so refined she can recommend obscure titles by Richard Bachman, John Swithen, and Beryl Evans — three pseudonyms King has used to publish lesser-known works that are absolute shibboleths among dedicated fans. In this way, you benefit from the librarian’s algorithmic amplification of alternatives that would have otherwise been unknown to you. 

Technical Description of an Algorithm

The non-technical description is good for a general idea of how algorithms work but it is not specific enough to demonstrate how abstractions are automated through computation. To do that we need a formal definition. For this purpose, I am taking the definition provided by Schneider and Gersting (12):

“Algorithm: a well-ordered collection of unambiguous and effectively computable operations that, when executed, produces a result and halts in a finite amount of time.” 

To put this definition in context, we can build on what was discussed in the last layer by thinking of an algorithm as the formal articulation of the process that converts inputs to outputs. 

A computer is a tool that automates “a well-ordered collection of unambiguous and effectively computable operations.” The defined inputs trigger the execution of those operations and the result is defined outputs. The caveat “halts in a finite amount of time” is specified because without a definite end point, an automated operation will go on forever. This is a phenomenon known as an “infinite loop.”  For example, imagine if you washed your hair accoridng to the algorithm on your shampoo bottle. If you did, you would wash your hair forever, or at least until you ran out of shampoo:

I am not going to say anything more about the technical definition of an algorithm right now, but I will return to it regularly throughout the Computing Information Disorder project.

In order to design an algorithmic solution to an information-based problem, one must have certain conceptual tools at their disposal that are very common among computer programmers and scientists but that are usually mysterious to anyone outside those fields. I have taken several of those concepts and configured them into a knowledge framework I call the “Comptuational Thniking Cycle” or “CT Cycle.” 

Once again, as in the previous layer, my start point for this framework was the work done by Berry and Fagerjord. However, they tend to treat computational concepts mostly as a menu of “cognitive practices” (40) whereas I am here attempting to instrumentalize those concepts into a coherent problem-solving methedology. I have thus departed from their work substantially when necessary.

To understand how a CT Cycle operates, let's consider another non-digital example. Imagine you own a restaurant. As a business, your restaurant is meant to generate profits by serving customers. Considered in this way, your restaurant is just like any other information processor. 

The “problem” you need your restaurant to solve is how to convert customer demand signal into money. You begin by decomposing that probelm into a hierarchy of smaller, component problems. The most important one will likely be the menu. So, you hire a chef to create a menu for your restaurant. You have  effectively modularized the solution-creation for that compnent problem. To you, the menu is a high-level problem. But to the chef, it is a series of smaller challenges that can be categorized according to patterns she is familiar with. For example, she can divide it into appetizers, main courses, and desserts. She will then create a series of abstractions, called dishes, that fall into those categories. She will experiment with each dish until she has something she thinks will be popular with customers. Once she has that collection of dishes, she will organzie them according to ingredients and preparation techniques so that she can start procuring foodstuffs and training staff.

For each dish, she will design a series of instructions to prepare the dish called a “recipe.” Those recipes will then become the procedures that determine how the cooks prepare the meals. The chef will then keep track of how well each dish performs with the customers and determine if it is profitable to your restaurant. If it is not, she will tweak it or perhaps remove it from the menu. 

This represents a full CT Cycle. The reason the cycle can be considered computational is because of the recipes the chef created. A recipe is an algorithm that automates a cooking process. To return to the technical definition above, a recipe is “a well-ordered collection of unambiguous and effectively computable operations.” In this scenario, the recipe is a good example of how an expert can automate a specialized service so that it can be outsourced to someone else; meaning, that the chef just has to create the recipe and train the cooks. She does not need to prepare every single meal. If you decide to put the chef in charge of the entire restaurant, she can now let that automated process handle the food preparation while she works on decomposing the rest of the other, unglamorous  challenges that come with being a restauranteur.

To conclude this layer, below is a CT Cycle taxonomy of the example just discussed.

1. Decomposition: Your restaurant will need a menu, so you isolate that problem from all the other challenges and modularize its resolution.

2. Pattern recognition: The chef breaks that problem down into smaller problems and groups them according to recognized categories of problems she knows how to solve.

3. Abstraction: The chef then uses those high-level problem categories to derive individual operations that will work out the low-level details of creating each indivdual dish.

4. Modelling: She then experiments with each dish to make sure it is something that will taste good and sell well.

5. Protocol Sequencing: Once she has a model worked out for each dish, the chef organizes the dishes according to the physical and human resources required to prepare them.

6. Automation: The chef then writes instructions for how to prepare each dish and implements those instructions through her cooks.

7. Assessment: She monitors how well each dish sells.

8. Adjustment: She tweaks the menu, the recipes, and the protocols based on the profitability of each dish.

In the next layer, I will apply this same cycle of analysis to the problem of Information Disorder.