Two papers for Anind Dey's talk on 2/02/96
ANIM- John L. Bentley and Brian W. Kernighan
Zeus- Marc H. Brown
ANIM is a very simplistic alogorithm animation program that can create crude, but useful animations. It is easy to use and easy to generate output. Advantages of using such a system include:
Disadvantages are:
Algorithm code can be written in any language. ANIM statements are embedded within the algorithm code, in the way of print statements. The print statements are used to generate an output script file. The script file is then read using the movie tool or stills tool, to provide a dynamic animation, or a bunch of snapshot of the algorithm at different points in time. ANIM allows a user to generate an animation with multiple views, each of which can contain any of the following primitives: lines, boxes, text, circles. Interesting events are denoted using the click tag.
Despite the notion that ANIM can only produce very crude animations, it has been used to produce some very sophisticated ones:
ANIM can be used on several terminal types. It makes use of simple objects, and while it is not object oriented, it is object-oriented-like in the way entities are accessed and used. ANIM provides a programmer with the ability to use multiple independent views to show sophisticated algorithms. Finally, the ANIM tools are very simple to use and have a small learning curve. ANIM trades the quality of the animation for the ease and simplicity of use. ANIM can be used for teaching, programming (debuggging), and research (quickly determining the relative value of several algorithms made to reach a common goal). For these tasks, the system does not need to be elaborate. The makers of ANIM believe that wide availability and ease of use are more important than a sophisticated animation.
In Marc Brown's Perspectives on Algorithm Animation, a taxonomy for categorizing algorithm animation systems is given. The taxonomy has three axes: transformation (state changes are discrete or incremental), content (animation content is taken directly from algorithm variables or synthesized), and persistence (animation is showing current state or past history). Applying this taxonomy to ANIM, it can be seen that ANIM lies on the discrete end of the transformation axis, on the past history end of the persistence axis, and can lie anywhere on the content axis (from direct to synthesized).
While the difference in the quality of animations produced by ANIM is quite different from those produced by ZEUS, are there algorithms that can be "effectively" animated in ZEUS, and not in ANIM?
Is the time saved by using ANIM as opposed to another system like ZEUS or TANGO, worth the result of a much cruder animation, in general?
ZEUS is an algorithm animation system that allows the user to view and interact with the animation and allows the programmer to develop the animation. It is based on the same principles as BALSA (both developed by Marc Brown). They both use the concept of annotationg algorithms with interesting events, and allow the creation of multiple view which make up the displays and are updated when they receive events.
ZEUS is noteworthy for the following reasons:
When using ZEUS, the user can choose the algorithm to animate, the views to create, and the input data. The speed of the animation is also under the user's control. Not only can the user input data, but he/she can also modify the data during run-time (not always a good thing). There are two views that are created automatically for the user: Transcript View listing all the interesting events that occur, and a Control Panel that allows the user to dynamically create interesting events with the appropriate parameters.
ZEUS is a "domain-independent framework for associating multiple client-defined views with a set of client-defined events, generated by a client program called the algorithm". The programmer typically would first write the algorithm code in the language used by ZEUS, a variant of Modula 2. A file is then defined that lists Class Names, Data Types, and Events (going from algorithm to the view, and views to the algorithm) used by the algorithm and animation. A preprocessor creates the interface between the views and algorithm, and creates the two automatic views. Views are created using a very simplistic graphics editor. Designing the layouts for the views is the hardest part of developing the animation. For each view, event processors must be written to handle events coming from the algorithm. The algorithm must be annotated with interesting events, which are sent to the various views.
There have been a couple of important additions that have been made to ZEUS. One is the GraphVBT interface. It is a simplified graphical interface to ZEUS. It implements only the most widely used components: views, vertices, edges, polygons, and vertex highlights. It allows the user to create animations and allows both discrete and incremental transitions. A second addition to ZEUS is GEF which runs with both ZEUS and GraphVBT. It makes use of a high level scripting language. The language is interpreted, flexible, expressive, and is designed for animating algorithms. Like GraphVBT, it uses a minimal set of components including all the components of GraphVBT plus arcs.
In Marc Brown's Perspectives on Algorithm Animation, a taxonomy for categorizing algorithm animation systems is given. The taxonomy has three axes: transformation (state changes are discrete or incremental), content (animation content is taken directly from algorithm variables or synthesized), and persistence (animation is showing current state or past history). Applying this taxonomy to ZEUS, it can be seen that ZEUS lies on the discrete end of the transformation axis, on the current state end of the persistence axis, and can lie anywhere on the content axis (from direct to synthesized).
It seems that most algorithm animation systems compare themselves to ZEUS, TANGO, and BALSA. It would be interesting to study why - what qualities do these systems have that others do not? And under what conditions would you use one over the other?
Both papers discussed dealt with discrete transistions. Under what circumstances would you require, or find beneficial, the use of incremental transitions between algorithm states? One argument is it depends on the amount of data being displayed. Large data sets can make use of discrete transistions because the visual differences in the transitions are so small. Small data sets require incremental transitions in order to show the user what is occuring in the algorithm, rather than having to view graphical entities pop from place to place, which usually isn't very informative.