insertion sort [20]. The user has to map the problem domain (values to be sorted) to the graphical domain. (bars), and then looking at the animation they have to.
A New Approach to Learning Algorithms Tomasz Müldner and Elhadi Shakshuki Jodrey School of Computer Science, Acadia University, Wolfville, NS, Canada {Tomasz.Muldner;Elhadi.Shakshuki}@acadiau.ca
Abstract Algorithm visualization aims to facilitate the understanding of algorithms by using graphics and animation to reify the execution of an algorithm on selected input data. However, many current visualization techniques suffer from a variety of problems, such as lack of focus, presentation at a single level of abstraction, and concentration on lowlevel steps rather than on high-level properties such as invariants. In this paper, we present a new approach to learning algorithms that aims to overcome these drawbacks. An algorithm is explained at various levels of abstraction. Each level is designed to present a single operation used in the algorithm. Operations are shown in a textual form of a pseudocode, but there is also an associated visualization.
1. Introduction Algorithms play an intrinsic role in Computer Science, and researchers have been trying to find the best way to learn and teach algorithms. One of the best known approaches uses visualization, with various kinds of multimedia [15]; including graphics, animation, video and auralization [5]. There are many papers describing the use of animation to software explanation [10]. These applications have various problems. First, executing the visualization, we simulate the code written in a textual language using a graphical language, and the representation is typically at the low level of abstraction that shows low level steps. Second, to explain an algorithm, too much emphasis is placed on meta-tools (graphics and animation) rather than the problem at hand. However, some studies [6] found that students interacting with an algorithm animation performed significantly better than students who listened to a lecture [13].
This paper describes an alternative and systematic procedure to explain algorithms, using a hierarchical algorithm abstraction model. In this model, a single abstraction level is designed to explain one operation used in the algorithm. For example, for a selection sort algorithm, the top level of abstraction is designed to explain the sort algorithm, using other operations, considered at this level to be primitive operations, such as , which finds the smallest element in the sequence. Therefore, each level of abstraction includes an abstract data type, ADT with data structures and operations. Operations are shown in a textual form, using the ADT. An optional visual representation can be used by the student to help him or her understand basic properties of this level of abstraction; for example algorithm invariants. In addition to the hierarchical abstraction model, an explanation of every algorithm includes various tools to estimate the complexity of this algorithm. The rest of the paper is organized as follows. Section 2 briefly describes related work on algorithm visualization. Section 3 describes our approach, and section 4 gives an example of the algorithm explanation. Finally, section 5 provides conclusions and describes future work.
2. Related Work Figure 1 shows a typical example of an algorithm animation - a screenshot from the animation of insertion sort [20]. The user has to map the problem domain (values to be sorted) to the graphical domain (bars), and then looking at the animation they have to retrieve essential properties of the algorithm (such as maintaining a sorted prefix). This system and many other existing algorithm animation systems resemble visual debuggers in that they show the execution of the algorithm by code-stepping, and illustrate only the primitive code. Therefore, this approach constrains users to view the code in the order of execution, which is the wrong information for understanding the
algorithm and has a poor cognitive fit with the planand-goal structures that users are trying to extract from the code [15]. In any case, runtime interpretation requires specific input data (cannot consider all possible inputs) and often suffers from the lack of focus on relevant data [4].
successfully derive invariants from the text then they do not need to see the visual representation. Thus, the visual representation is used to help reason about the textual representation. The target audience is students who know well programming and intent to learn algorithms.
3.1. Goals and Requirements
Figure 1. Animation of insertion sort.
In addition, most existing systems do not attempt to visualize or even suggest essential properties, such as invariants, which are essential for understanding algorithm correctness. One notable exception is the approach in [21], which uses a static source code analysis to abstractly execute the algorithm on “all possible sets of input data”, and visualize invariants. Also, there have been very few attempts to visualize recursive algorithms; the most notable example is given in [18, 19].
3. Algorithm Explanation This section describes our proposed approach, called Algorithm Explanation (AE). The main goal of AE is to support the task of algorithm comprehension for which learning becomes of more interest than teaching. According to [16] to make this task possible, the learner has to build a mapping from the domain consisting of the algorithm entities and temporal events to learner’s conceptions of these entities and events. AE uses a variety of tools to help the students to learn algorithms, and visualization is just one possible tool. Indeed, we provide both, textual and visual representation. The latter is used to help students recognize and understand algorithm properties. Note that two representations are not necessarily better than one; see [16]. As we will explain in section 4, we use a visual representation to help student derive essential properties, such as invariants. However, we leave the option of using just the text, and if the students can
The following goals should be achieved to develop our proposed system: G1. Understanding of both, what the algorithm is doing and how it works. G2. Ability to justify the algorithm correctness (why the algorithm works). G3. Ability to program the algorithm in any programming language. G4. Understanding the time complexity of the algorithm. To achieve the above goals, the following requirements must be satisfied: 1. the algorithm is presented at several levels of abstraction 2. each level of abstraction is represented by the text and optionally by visualization 3. active learning is supported 4. the design helps to understand time complexity 5. presentations are designed by experts. The following sub-sections briefly elaborate on of these requirements. 3.1.1. Multiple Levels of Abstraction. The research in cognitive psychology on knowledge organization supports using multiple levels of abstraction when dealing with complex tasks [2]. In our approach, each level of abstraction is used to highlight a single kind of information; for example invariants, and so the student can focus on this kind of information. This helps setting up a mental model of each state of an algorithm [16]. There are two possible ways that algorithm abstraction levels may be defined. For both ways, the top level is first defined, using operations that are considered primitive at this level. With the first way, each top level primitive is defined at the single lower abstraction level, possibly using other primitives (those primitives would be defined at the next lower abstraction level); see [7]. With the second way, the top level primitives are replaced (rather than defined) by their definitions, which again can use some lower-level primitives. Thus, the second way resembles code inlining. We adopted the first way, which helps to concentrate at issues pertinent to one abstraction level.
3.1.2. Pseudocode Representation. The pseudocode is a part of the model of the algorithm, and it includes the high-level abstract data structures and operations. Using pseudocode, the algorithm can be studied independently of any programming language [8]. The pseudocode given at each level of abstraction has an optional visual representation, which exposes its properties, in particular its invariants. This approach is supported by findings provided in [16]. 3.1.3. Active Learning. Active learning follows the Cognitive Constructivism principles, including various kinds of interactions with the student [13]. For example, students are able to use their own input data sets; use a do-it-yourself mode, that is predict the next step of the algorithm [18, 19], and then determine the essential algorithm properties. AE always comes with several sets of representative sample input data; the learners can also use their own input data. Also, AE includes post-tests [17], with tasks such as handexecution of the algorithm on sample sets of input data, and answering various questions about the algorithm. 3.1.4. Time Complexity. Explanation of algorithm complexity is one of the most difficult goals of algorithm visualization, because it requires mathematical proofs that are hard to visualize. There are three kinds of tools designed to help the student to derive the complexity of the algorithm being studied. The first tool is based on ideas from [12], and it gives the student a chance to experiment with various data sizes and plot a function that shows the approximate time spent on execution with these data. The second tool is based on ideas from [11], and it provides a visualization that helps to carry out time analysis of the algorithm for specific examples. Finally, the third tool asks students various questions regarding the time complexity, and evaluates their answers. 3.1.5. Multiple Views. Multiple views showing algorithm states are used to avoid forcing the viewer to remember the previous states. This is demonstrated by two consecutive frames in the “comic strip" approach [3]. 3.1.6. Design by Experts. AE presentations are designed by experts who have a complete understanding of essential properties to be exposed, such as invariants. Our approach is similar to that used in design patterns, which are created by experts and used by novices. It is also similar to the concept of “algorithmic design patterns”, described in [11].
3.2. AE Descriptions The ultimate goal of our research is to develop an AE catalog, consisting of AE descriptions of many well known algorithms. Each description, or catalog entry, consists of the following four parts: 1. Hierarchical Abstract Algorithm Model; for each level there is a textual representation and an optional visual representation. The textual representation includes an Abstract Data Type, which provides data and operations. 2. Example of an abstract implementation of the Abstract Algorithm Model (to help the student to write concrete implementations). 3. Tools to help predicting the algorithm complexity. 4. Questions for students, including “do it yourself” mode for each level of abstraction. Various kinds of algorithms require different approaches, in particular different visualizations. Iterative algorithms can be explained using an operational semantics (state, transition and next state), from which the student is supposed to derive the code and invariants. Recursive algorithms require a different treatment. This paper describes only iterative algorithms, and does not describe the above part 2 of a catalog entry [14].
4. An Example: Selection sort In this section, we describe the selection sort [1] to demonstrate the functionalities of our proposed system.
4.1. Leveled Abstraction Model The top level of abstraction provides the abstract data model, the pseudocode and visualization of the algorithm. 4.1.1. Top Level of Abstraction. The ADT consists of sequences of elements of type , denoted by , with a linear order. In general, this order can be defined in one of three ways: 1. Type supports the function so that returns -1 if is less than , 0 if they are equal and +1 otherwise. 2. Type supports the “ ” operation, which can be used to compare two elements of this type. 3. There is a function (or a type) which returns -1 if and +1 otherwise.
is less than , 0 if they are equal
The goal of the selection sort algorithm is to sort the sequence according to the given comparator, and so this algorithm has the following signature: In this paper, we only consider the third comparing function; the description for two other options is almost identical. The above model is completely generic, in particular it does not specify concrete data structures; for example we can use arrays or linked lists. Also, it does not specify details of the algorithm, for example whether it works “in place”, or with copying. The following operations on an element of the domain are available: , possibly empty ( ), which can be incremented by one element; , where a prefix followed by the suffix is equal to the entire sequence ; , which returns the first element of the suffix; , which finds the smallest element in (using ); ! " # , which swaps " and #. The student is provided with the abstract data model and the pseudocode shown in Figure 2, and asked to determine invariants of this code.
conventions used by our visualization: data are represented by rectangles; the height of a rectangle represents the value of this data. A box with a thin boarder represents the prefix of a sequence (in this figure the prefix is empty), and a box with a thick boarder represents the suffix.
Figure 3. Conventions used by the visualization.
Figure 4 shows the first few states resulting from the execution of the pseudocode, using a five sample input data. This visualization clearly shows both invariants: the prefix box is smaller than the suffix box, which visualizes the first invariant, and all elements in the prefix are sorted, which shows the second invariant.
$ %
&
'% & (
!
&
) Figure 2. Pseudocode for selection sort.
In this example, there are two invariants: 1. All elements in the prefix are smaller (according to the “comp” relation) than all elements in the suffix. 2. The prefix is sorted. The first invariant is true because in each step of the “for” statement, the smallest element in the suffix is placed at the beginning of the suffix, and then the prefix is incremented, effectively placing this element at the end of the prefix. Once this invariant is established, the second invariant easily follows: appending the element from the suffix to the end of the prefix maintains the “sortedeness” of the prefix. Since the algorithm stops when the prefix contains all the elements in the sequence, the second invariant shows the correctness of this algorithm – it indeed sorts the sequence. It may be hard for the student to find both these invariants and if they wish so, they can use the associated visualization [7]. Figure 3 shows
Figure 4. Partial visualization of selection sort at the top level of abstraction.
4.1.2. Low Levels of Abstraction. There are two additional levels of abstraction, respectively to represent the operations ! and from the ADT described in Section 4.1.1. Since the first operation is fairly trivial, this paper only shows in Figure 5 the pseudocode for the second operation. $ %
& ! %
&
) Figure 5. Pseudocode for the function smallest.
Also, in this paper, the visualization associated with the above pseudocode is not shown.
4.2. Post Test In this section, we provide a sample of the list of questions for the selection sort algorithm: Q1. What is the number of comparisons and swaps performed when selection sort is executed for a sorted sequence and a sequence sorted in reverse. Q2. What is the time complexity of the function , which checks if is a sorted sequence? Q3. Hand-execute the algorithm for a sample set of input data of size 4. Q4. Hand-execute the next step of the algorithm for the current state. Q5. What’s the last step of the algorithm?
5. Conclusions and Future Work This paper described a new approach for learning algorithms, and the system based on this approach, in which an algorithm is explained at various levels of abstraction. Each level is designed to present a single operation used in the algorithm. All operations are shown in a textual form of a pseudocode associated with visual description, used to help the student understand basic properties of the algorithm. The major requirements of the system include: multiple levels of abstraction, pseudocode representation, active learning, explanation of time complexity, multiple views, and design by experts. The visualization system presented in this work is implemented using Macromedia Flash MX [22]. Our current work concentrates on the architecture and functionality of the proposed system and the implementation of user friendly graphical interfaces. Furthermore, we are currently working on a complete system with a student model to provide an intelligent and adaptive learning system.
References [1] Aho, A. V., Hopcroft, J.E., and Ullman, J. D., Data Structures and Algorithms. Addison-Wesley, Reading, Mass. 1983. [2] Anderson, J. R. Cognitive Psychology and its implications. San Francisco: Freeman, 1980. [3] Biermann, H. & Cole, R., “Comic Strips for Algorithm Visualization”, NYU Technical Report 1999-778, 1999. [4] Braune, B. & Wilhelm, R., “Focusing in Algorithm Explanation”, IEEE Transactions on Visualization and Computer Graphics 6(1), pp. 1-7, 2000. [5] Brown, M.H., & Hershberger, J., “Program Auralization”, In Stasko, Domingue, Brown, &. Price (Eds.), Software Visualization: Programming as a Multi-Media Experience, MIT Press, pp. 137-144, 1998.
[6] Crosby, M. & Stelovsky, J., “From Multimedia Instruction to Multimedia Evaluation”. Journal of Educational Multimedia and Hypermedia 4, pp. 147-162, 1995. [7] Feng Zhe, “Algorithm Visualization: Using Various Levels of Abstraction and Invariants”, Honours Thesis, Acadia University, 2003. [8] Fleischer, R., & Kucera, L., “Algorithm Animation for Teaching”, Springer LNCS issue on Software Visualization, S. Diehl (Ed.): Software Visualization International Seminar, Dagstuhl Castle, Germany, Revised Papers LNCS 2269, pp. 113-128, 2001. [9] Gamma, E., Helm, R., Johnson, J. & Vlissides, J., Design Patterns Elements of Reusable Object-Oriented Software. Addison-Wesley, Reading, Mass, 1995. [10] Gloor, P. A., “Animated Algorithms”. In Stasko, John Domingue, Brown, & Price (Eds.), Software Visualization: Programming as a Multi-Media Experience, MIT Press, pp. 409-416, 1998. [11] Goodrich, M. & Tamassia, R., Data Structures and Algorithms in Java, John Wiley & Sons, Inc., 2001. [12] Horstmann, C., Big Java: Programming and Practice. John Wiley & Sons, 2001. [13] Hundhausen, C.D., Douglas, S.A. & Stasko, J.T., “A Meta-Study of Algorithm Visualization Effectiveness”, Journal of Visual Languages and Computing 13(3), pp. 259290, 2002. [14] Müldner, T., An Algorithm for Explaining Algorithms. Technical Report TR-2003-01, Acadia University, 2003. [15] Petre, M., Baecker, R. & Small, I., “An Introduction to Software Visualization”. In Stasko, Domingue, Brown, & Price (Eds.), Software Visualization: Programming as a Multi-Media Experience, MIT Press, pp. 3-26, 1998. [16] Petre, M., Blackwell, A. F. & Green, T. R. G., “Cognitive Questions in Software Visualization” ibidem p. 453-480, [17] Stasko, J. & Lawrence, A., “Empirically Assessing Algorithm Animations as Learning Tools” ibidem p.417-419 [18] Stern, L. & Naish, L., “Animating Recursive Algorithms”, Interactive Multimedia Electronic Journal of Computer Enhanced Learning, Vol. 4, No. 2, 2002. [19] Stern, L. & Naish, L., Visual Representation for Recursive Algorithms. In Proceedings of the 33rd Annual SIGCSE Technical Symposium on Computer Science Education, ACM, pp. 196-200, 2002. [20] Whitley, J. & King, A., Animation of insertion sort, http://www.cs.duke.edu/courses/spring01/cps049s/students/a ck11/jawaasorting.html, 2001. [21] Wilhelm, R., Müldner, T. & Seidel, R., “Algorithm Explanation: Visualizing Abstract States and Invariants”, Springer LNCS issue on Software Visualization. S. Diehl (Ed.). Revised Papers LNCS 2269, pp. 381-394, 2001. [22] Macromedia Flash MX. (2003) http://www.macromedia.com/software/flash/.
