Algorithms and Their Explanations

Algorithms and Their Explanations

• 1.
  Algorithms and TheirExplanations CiE 2014 — History and Philosophy of Computing 24th June 2014 M Benini1 F Gobbo2 1Università degli Studi dell’Insubria marco.benini@uninsubria.it 2Universiteit van Amsterdam F.Gobbo@uva.nl
• 2.
  Introduction The purpose ofthis 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 is hidden, 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., the explained object B, as well as the beneficiary C are clearly defined. On the contrary, the explaining agent A remains implicit, and also the level of abstraction M. (2 of 18)
• 3.
  The Method ofthe Levels of Abstraction In Floridi’s approach to the Philosophy of Information, an explanation is always understood on one or more Levels of Abstraction (LoAs), clearly defined. 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, the agent C has to “understand” the purpose, and he has also to use an amount of knowledge and information to build the new LoA N. Collectively, the purpose 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 by B in order to construct the LoA N. (3 of 18)
• 4.
  Minimal information So, fixeda context, the question we want to address is: What amount of information the agent needs in order to construct the required level of abstraction N over the given one M? This is best understood looking at a concrete example: the Heapsort algorithm. It has been chosen because it is simple although not trivial, and it 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: we can focus just on the analysis of explanations. (4 of 18)
• 5.
  The scenario A softwarehouse has to produce a program to solve some given problem. Its employees are the programmer who has to convert a given specification to a working code in some programming language; the software designer who has to analyse the problem and to describe an algorithmic solution which becomes the set of specifications; the algorithm designer who takes the general specifications from the software designer and convert them into precise descriptions of what the programmer must implement. Each of these agents are part of an informational organism (inforg) which is given by the agent and the computer where the program has to be implemented. In turn, each of these inforgs has an appropriate LoA the agent acts upon. (5 of 18)
• 6.
  The programmer’s view Theprogrammer receives a specification, in the form of an algorithm. His purpose is to code this into an executable piece of code. In our example, the specification is the Heapsort algorithm. The programmer’s LoA is given by the programming language, in a broad sense, and by the view of the machine he has through the language. Our question becomes: What “explains” the Heapsort algorithm to the programmer, enabling him to successfully achieve his purpose? (6 of 18)
• 7.
  The Heapsort algorithm Heapsort(A: array) ≡ BuildMaxHeap(A) for i ←len(A) downto 2 do exchange(A[1],A[i]) heapsize(A)←heapsize(A)−1 MaxHeapify(A,1) BuildMaxHeap(A : array) ≡ heapsize(A)←len(A) for i ← len(A)/2 downto 1 do MaxHeapify(A,i) left(i : N) ≡ 2i right(i : N) ≡ 2i +1 MaxHeapify(A: array,i : N) ≡ m←i l ←left(i) r ←right(i) if l ≤ heapsize(A) & A[l] A[m] then m←l if r ≤ heapsize(A) & A[r] A[m] then m←r if m = i then exchange(A[i],A[m]) MaxHeapify(A,m) exchange(a: element,b: element) ≡ x ←a; a←b; b ←x (7 of 18)
• 8.
  The programmer’s explanation Theprogrammer needs to know how to read the specification and to correctly convert it into an executable piece of code in the programming language. In other words, he has to build a new LoA, which extends the programming language with a new function, Heapsort. Thus, the minimal explanation the programmer needs of the above pseudo-code is the one which allows him to fulfil his task. This explanation reduces to know how to correctly interpret the pseudo-code into the programming language construction. E.g., he needs to know that ← stands for assignment. This amount of explanation suffices to show that the implementation exactly matches the pseudo-code, and so, it is correct with respect to the specification the programmer is given. (8 of 18)
• 9.
  The software designer’sview The purpose of the software designer is to construct a set of specifications that collectively allows to write a program that solves the problem. The software designer, in our example, has reduced a part of the solution to the need of sorting an array. So, he has to understand what are the features this sorting algorithm must have. For example, he has to decide that stability does not matter, while efficiency is important. For a software designer, an algorithm is not a procedure, but a collection of properties. He has to decide what properties are relevant to solve the problem, and to pass them to the algorithm designer, who converts them into pieces of pseudo-code, and then, to the programmer, who convert the pseudo-code into an executable program. (9 of 18)
• 10.
  The software designer’sexplanation After identifying sorting as a (sub-)problem to be solved, the software designer has to decide what the sorting procedure should actually do. For him, the “right” sorting procedure must exhibit some features, while it may not 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 he provides is correct, i.e., it solves the original problem within the given constraints. Note how the software designer does not need to know how Heapsort operates! (10 of 18)
• 11.
  The algorithm designer’sview As the software designer is interested in “what” an algorithm does, the algorithm designer focuses on “how” an algorithm achieves its result. In our example, the algorithm designer may think that sorting data in a tree is 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 key is less than the parent’s. Understanding that an array can be interpreted as a tree, allows to write an algorithm that does not use an additional data structure. In this way, eventually, the algorithm designer will be able to prove that the designed pseudo-code, which is the previously shown Heapsort procedure, is correct, that is, it sorts an array. Also, destructive manipulation of the input and 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 recursive equations. And the solution of these equations clearly shows that Heapsort operates in O(nlogn) with n the length of the array. (11 of 18)
• 12.
  The algorithm designer’sexplanation So, the algorithm designer is able to show that his pseudo-code, the LoA he constructed, satisfies the specification he received. To provide this evidence, he has to show that the pseudo-code sorts an array and do it within the constraints put by the software designer, which amounts to explain how the computational process he designed eventually produces the output; to calculate the complexity of the algorithm, which amounts to deduce from the algorithm and to solve a set of recurrence equations. The knowledge and information to obtain these two goals are essential to justify his work, so this is the minimal explanation which suits the algorithm designer’s purpose. (12 of 18)
• 13.
  The Minimal Levelsof Abstraction When the purpose has been accomplished, the resulting machine shows (at least) 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 being in strict interaction with a corresponding level of observation, which enables us to measure information. Although very simple, these two LoAs provide a gradient of abstractions: the description 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 mutual interactions. (13 of 18)
• 14.
  The Levels ofExplanation of an Algorithm The Heapsort procedure as implemented can be explained in, at least, four different 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 one of the explaining agent. In the last three cases this has been already illustrated, while in the first, the purpose is simply to execute the procedure on a given input. (14 of 18)
• 15.
  A gradient ofexplanation In Floridi’s terms, each complex, structured information, is understood on one of more Levels of Abstractions (LoAs), where each one presumes a Level of Explanation (LoE) that is used to construct what we informally called explanation. And, the four explanations are strictly linked one to the others, together providing an explanation for (part of) the purpose of the software house: to provide a program that solves a specific problem. (15 of 18)
• 16.
  Minimal explanations andmeasures A gradient of explanations allows for a very simple way to measure distance between explanations: we say that the machine “understands” the code less than the software designer because the explanation of the machine is at level 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 a LoA: it does not make sense to use it outside this context. Nevertheless, this measure can be made more “objective” when we consider minimal explanations — as we tried to do — because any other gradient of explanations on the same LoA and inforgs would become an extension of the minimal one. (16 of 18)
• 17.
  Conclusion The concept ofthe Gradient of Explanations (GoE) presented here was naturally derived within the Method of the LoAs. It is important to note, that the GoE has a different epistemological status compared to the Gradient 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 will act as a concrete guideline so to apply the GoE in other cases. (17 of 18)
• 18.
  Thank you foryour attention! (18 of 18)