Algorithms and Their ExplanationsCiE 2014 — History and Philosophy of Computing

24th June 2014

M Benini1 F Gobbo2

1Università degli Studi dell’Insubriamarco.benini@uninsubria.it

2Universiteit van AmsterdamF.Gobbo@uva.nl

Introduction

The purpose of this talk is to speak about explanations of algorithms.

The term explanation is understood in the following sense:■ the verb to explain has the paradigmatic form “A explains B to C”;■ the noun explanation denote the act of explaining where the subject A ishidden, i.e., “explanation of B to C”;

■ the explanation is proposed on a given level of abstraction M set by A,living in a given context.

Therefore, an explanation lives in a context where the explanandum, i.e., theexplained object B, as well as the beneficiary C are clearly defined.

On the contrary, the explaining agent A remains implicit, and also the levelof abstraction M.

(2 of 18)

The Method of the Levels of Abstraction

In Floridi’s approach to the Philosophy of Information, an explanation isalways understood on one or more Levels of Abstraction (LoAs), clearlydefined. In other words, the explanation of B to be grasped:■ has to be implemented by the agent C ;■ over another LoA N;■ N is, again, part of the context, like M.

The subject A provides the purpose of the implementation to B; in turn, theagent C has to “understand” the purpose, and he has also to use an amountof knowledge and information to build the new LoA N. Collectively, thepurpose and the used information are called Level of Explanation (LoE).

Evidently, the LoE is (at least in part) implicit and so it should be elicited byB in order to construct the LoA N.

(3 of 18)

Minimal information

So, fixed a context, the question we want to address is:What amount of information the agent needs in order to construct therequired level of abstraction N over the given one M?

This is best understood looking at a concrete example: the Heapsortalgorithm. It has been chosen because it is simple although not trivial, andit illustrates in a nutshell all the fundamental aspects of the above question.

Also, since it is classical, there is no need to explain it in the first place: wecan focus just on the analysis of explanations.

(4 of 18)

The scenario

A software house has to produce a program to solve some given problem. Itsemployees are■ the programmer who has to convert a given specification to a workingcode in some programming language;

■ the software designer who has to analyse the problem and to describe analgorithmic solution which becomes the set of specifications;

■ the algorithm designer who takes the general specifications from thesoftware designer and convert them into precise descriptions of what theprogrammer must implement.

Each of these agents are part of an informational organism (inforg) which isgiven by the agent and the computer where the program has to beimplemented. In turn, each of these inforgs has an appropriate LoA theagent acts upon.

(5 of 18)

The programmer’s view

The programmer receives a specification, in the form of an algorithm. Hispurpose is to code this into an executable piece of code. In our example, thespecification is the Heapsort algorithm.

The programmer’s LoA is given by the programming language, in a broadsense, and by the view of the machine he has through the language.

Our question becomes:What “explains” the Heapsort algorithm to the programmer, enablinghim to successfully achieve his purpose?

(6 of 18)

The Heapsort algorithm

Heapsort(A : array)≡BuildMaxHeap(A)for i ← len(A) downto 2 do

exchange(A[1],A[i ])heapsize(A)←heapsize(A)−1MaxHeapify(A,1)

BuildMaxHeap(A : array)≡heapsize(A)← len(A)for i ←blen(A)/2c downto 1 do

MaxHeapify(A, i)

left(i : N)≡ 2i

right(i : N)≡ 2i +1

MaxHeapify(A : array, i : N)≡m← il ← left(i)r ← right(i)if l ≤ heapsize(A)&A[l ]ÂA[m]

then m← lif r ≤ heapsize(A)&A[r ]ÂA[m]

then m← rif m 6= i then

exchange(A[i ],A[m])MaxHeapify(A,m)

exchange(a : element,b : element)≡x ←a;a←b;b←x

(7 of 18)

The programmer’s explanation

The programmer needs to know how to read the specification and tocorrectly convert it into an executable piece of code in the programminglanguage. In other words, he has to build a new LoA, which extends theprogramming language with a new function, Heapsort.

Thus, the minimal explanation the programmer needs of the abovepseudo-code is the one which allows him to fulfil his task. This explanationreduces to know how to correctly interpret the pseudo-code into theprogramming language construction. E.g., he needs to know that ← standsfor assignment.

This amount of explanation suffices to show that the implementation exactlymatches the pseudo-code, and so, it is correct with respect to thespecification the programmer is given.

(8 of 18)

The software designer’s view

The purpose of the software designer is to construct a set of specificationsthat collectively allows to write a program that solves the problem.

The software designer, in our example, has reduced a part of the solution tothe need of sorting an array. So, he has to understand what are the featuresthis sorting algorithm must have. For example, he has to decide thatstability does not matter, while efficiency is important.

For a software designer, an algorithm is not a procedure, but a collection ofproperties. He has to decide what properties are relevant to solve theproblem, and to pass them to the algorithm designer, who converts theminto pieces of pseudo-code, and then, to the programmer, who convert thepseudo-code into an executable program.

(9 of 18)

The software designer’s explanation

After identifying sorting as a (sub-)problem to be solved, the softwaredesigner has to decide what the sorting procedure should actually do. Forhim, the “right” sorting procedure must exhibit some features, while it maynot have others because irrelevant to the solution he designs.

Thus, the explanation of HeapSort is, for him, a collection of properties:■ it sorts an array;■ it rearranges the input, instead of generating a sorted copy;■ it is not stable;■ it is efficient among comparison-based sorting algorithms.

This explanation allows the software designer to show that the solution heprovides is correct, i.e., it solves the original problem within the givenconstraints.

Note how the software designer does not need to know how Heapsortoperates!

(10 of 18)

The algorithm designer’s viewAs the software designer is interested in “what” an algorithm does, thealgorithm designer focuses on “how” an algorithm achieves its result.

In our example, the algorithm designer may think that sorting data in a treeis more efficient than sorting data in a random-access sequence. Of course,this is true when the tree satisfies some conditions, like that each node’s keyis less than the parent’s.

Understanding that an array can be interpreted as a tree, allows to write analgorithm that does not use an additional data structure.

In this way, eventually, the algorithm designer will be able to prove that thedesigned pseudo-code, which is the previously shown Heapsort procedure, iscorrect, that is, it sorts an array. Also, destructive manipulation of the inputand lack of stability immediately follow from the correctness proof.

Showing that Heapsort is efficient requires to reduce the execution time,measured as number of computational steps, to a set of mutually recursiveequations. And the solution of these equations clearly shows that Heapsortoperates in O(n logn) with n the length of the array.

(11 of 18)

The algorithm designer’s explanation

So, the algorithm designer is able to show that his pseudo-code, the LoA heconstructed, satisfies the specification he received. To provide this evidence,he has■ to show that the pseudo-code sorts an array and do it within theconstraints put by the software designer, which amounts to explain howthe computational process he designed eventually produces the output;

■ to calculate the complexity of the algorithm, which amounts to deducefrom the algorithm and to solve a set of recurrence equations.

The knowledge and information to obtain these two goals are essential tojustify his work, so this is the minimal explanation which suits the algorithmdesigner’s purpose.

(12 of 18)

The Minimal Levels of Abstraction

When the purpose has been accomplished, the resulting machine shows (atleast) two levels of abstraction:1. the LoA which has been used to implement Heapsort over it;2. the LoA which has Heapsort as a primitive.

Each of these LoAs can be described within Floridi’s framework, thus beingin strict interaction with a corresponding level of observation, which enablesus to measure information.

Although very simple, these two LoAs provide a gradient of abstractions: thedescription of the system used by the software house of our example is,really, the gradient, i.e., the sum of the two LoAs together with their mutualinteractions.

(13 of 18)

The Levels of Explanation of an Algorithm

The Heapsort procedure as implemented can be explained in, at least, fourdifferent ways:1. to the machine, it is explained by the operational semantics, encoded in

the computer machinery, which allows to execute the code.2. to the programmer, it is explained as the adherence to the pseudo-code;3. to the system designer, it is explained as a set of properties that allows

the procedure to take its role inside the program;4. to the algorithm designer, it is explained as an algorithm which solves a

useful problem, and which enjoys a number of “good” properties;

Each Level of Explanation (LoE) allows to fulfil a specific purpose, the oneof the explaining agent. In the last three cases this has been alreadyillustrated, while in the first, the purpose is simply to execute the procedureon a given input.

(14 of 18)

A gradient of explanation

In Floridi’s terms, each complex, structured information, is understood onone of more Levels of Abstractions (LoAs), where each one presumes a Levelof Explanation (LoE) that is used to construct what we informally calledexplanation.

And, the four explanations are strictly linked one to the others, togetherproviding an explanation for (part of) the purpose of the software house: toprovide a program that solves a specific problem.

(15 of 18)

Minimal explanations and measures

A gradient of explanations allows for a very simple way to measure distancebetween explanations: we say that the machine “understands” the code lessthan the software designer because the explanation of the machine is atlevel 1 in the gradient, while the software designer’s is at level 3.

It is important to remark that this measure is relative to a gradient and aLoA: it does not make sense to use it outside this context.

Nevertheless, this measure can be made more “objective” when we considerminimal explanations — as we tried to do — because any other gradient ofexplanations on the same LoA and inforgs would become an extension of theminimal one.

(16 of 18)

Conclusion

The concept of the Gradient of Explanations (GoE) presented here wasnaturally derived within the Method of the LoAs. It is important to note,that the GoE has a different epistemological status compared to theGradient of Abstractions (GoA).

The consequences of the introduction of the GoE are not yet fully explored,and its formalisation is still preliminary. However, the Heapsort example willact as a concrete guideline so to apply the GoE in other cases.

(17 of 18)

Thank you for your attention!

(18 of 18)