Algorithms and Algocracy – I

While the concept of algorithms has been around for centuries, the same cannot be said about algocracy. The latter has recently gained notoriety thanks partly to the renaissance of Artificial Intelligence and Machine Learning (AI/ML) and is frequently used to describe the increased use of algorithms in decision-making and governance processes. Indeed, the so-called Singularity could be seen as an extreme and seemingly irreversible algocracy case where humans lose the capacity to control superintelligent machines and might even face extinction. I’m not sure whether that will ever happen, though.

A more plausible scenario occurs when humans and institutions blindly rely on algorithms to make critical decisions. This is happening today in many sectors – the quasi-dictatorship of algorithms. In this context, the concept of algocracy seems to reify algorithms as they apparently have a life of their own and can single-handedly call most, if not all, shots. Yet, humans seem content with sitting on the fence, dutifully enjoying the view. Why is this happening?

We first must look more closely at algorithms to improve our understanding of this sad and curious state of affairs. So what is an algorithm, really? Compared to blockchain technologies, algorithms are indeed lagging far behind when it comes to online guides and digital videos trying to explain the concept ad nauseam. So let us not go there. Instead, allow me to use a non-digital example to illustrate the concept.

Solving complex puzzles

I still vividly recall the Rubik’s Cube boom of the last century. While I never bought one, several of my friends did. I was challenged to solve the puzzle to demonstrate my level of intelligence. I decided to confirm I was indeed irremediably dumb, and never went for it. Even if one were to solve it one time, the subsequent challenge was to replicate success quickly and thus salvage the genius reputation. Chess was (and still is) my cup of tea regarding board games and puzzles. Moreover, I had already learned how to code and was sure the cube solution would eventually be programmed.

The original cube had six different colors, each having nine squares. The goal was to arrange a scrambled cube by rotating its moveable edges so that all similar squares were placed on the same side for every color. There are several ways to solve this puzzle. But, of course, the ultimate goal is to minimize the number of rotations and the amount of time required. It turns out the former is twenty. This solution is known as God’s Algorithm and is used to solve similar puzzles. Moreover, the cube can now be unscrambled in less than one second thanks to robotics (AI/ML!) and digital algorithms.¹ Cooking recipes have also been used to illustrate algorithms. But recipes are prone to sequential changes that might have no impact whatsoever on the final output.

But now, we have sufficient ammunition to define an algorithm in simple terms. An algorithm comprises a series of limited, effective and sequential commands designed to efficiently tackle a specific task under particular given or initial conditions.

In the case of Rubik’s cube, the mission is to unscramble the cube. The cube itself provides the requirements, a small tangible object with six colors, nine squares per color, eight corners and twelve sides.² The last two features are critical to solving the puzzle via algorithms! The algorithm developed is effective as it achieves the goal and has a limited number of sequential commands that can be completed efficiently timewise.

Computer algorithms

The sorting algorithm was first taught to most computer programming students. I soon learned that multiple ways to sort a given text or data exist, each with its own algorithm with a proper name. It all depends on the initial set of conditions and the input provided. Generally, the creation of an algorithm entails two distinct steps. The first consists of devising a strategy to tackle the task and determine the best or most optimal approach. The result of this process is called pseudocode, which is a high-level and abstract set of instructions required to achieve the goal. It must then be translated into actual computer code, step two. To write the latter, one must have mastered some programming languages (C, C++, Java, Python, Solidity, etc.).

Four points are worth highlighting here. First, the division of labor between strategy and actual code is significant as one does not necessarily need to be an expert programmer to develop some basic pseudocode, especially if the targeted task is part of one’s daily work. Most seem to think that only programmers can generate pseudocode. Not exactly. Just think about all those well-known pop musicians who compose songs without knowing how to read or write music. Sure, they will eventually need “programmers” to write down the music so it can be arranged, recorded and performed publicly. However, the music’s copyright still belongs to the composer.

Second, actual computer programming generally involves adding other algorithms to the mix. For example, in the sorting algorithm, one might need to run a “cleaning” algorithm to ensure the integrity of the input data and then add at least another to display the final output. Algorithms rarely run standalone. Instead, they seem to be social animals demanding interaction with others. Computer programs comprise a series of algorithms that interact to yield the desired set of outputs. Such interactions add complexity and increase the potential for errors.³ The development of computer programs is usually based on software specification requirements, not just pseudocode.

Third, humans are directly involved in the overall process. While mentioning this might seem tautological, the critical issues here are as follows: 1. Algorithms are not static; new technologies, mathematics and other developments help introduce new ways of addressing a particular task. Innovation plays a part here. And 2. Coding by humans opens the door for biases, errors, and bugs, which can generate unwanted or harmful results together. Something is thus lost in translation. More often than not, finding such pitfalls becomes a complex operation itself. But they are there for sure.

Finally, the fundamental importance of the initial conditions for developing an algorithm is noted. In the case of Rubik’s cube, the initial conditions are static as we deal with a relatively small physical object. More giant cubes with more squares are available. But in the end, we can only handle so much. While having distinct engineering constraints, algorithms running on digital computers do not face such physical limitations. Undoubtedly, they are much more potent in addressing more complex computational tasks. But they still live on what humans feed them and are not picky about it.

In the next post, we will examine the role AI/ML has played in the evolution of algorithms and then briefly overview advocacy.

Cheers, Raúl