Discussion Questions from CS 7390 lecture

Date: 2/2/96

Presented by: Anind

Topic: Algorithm Animation 3

About Zeus:

• Brown claims that one can develop ... A view before - and even without - implementing an algorithm! How does the view know what the events are without the algorithm? What's the use of such a view?
• It seems that the programmer has to do a lot of work to set up anything more than just a rudamentary animation. First, he must annotate the code, then create the Zume input file, and finally write the event interpretors that display the events. While there are some library calls that simplify this task, it seems that most of the display functions must be written by the programmer. Why go through the trouble of learning Zeus when all of this could just as easily be accomplished with a standard graphics package?
• Is Zeus using a mixture of object-oriented techniques and UNIX-like filtering tools?
• Zeus uses type info from some compiler tools. Could Polka do type-safe AlgoEvents without compiler help? What sort of info from the compiler would be useful for doing algorithm animation? And what could the language design contribute to making algorithm animation easier?
• The Zeus paper introudes another object-oriented animation system. It adds strong type checking and strongly recommends that this is important for event handling. However, they make no argument for why this is so important. How does type checking add to the strength of an animation system?
• Zeus uses event driven methods for problem control, which is natural to algorithm animation, because what's being animated are sequences of events. How can events be captured semi-automatically, which means the system suggests significant events to animate and creates primitive views for them and then gets improved by the programmer?
• In a multithreaded environment, synchronization between the algorithm and the views is important if each has its own thread. For instance, the algorithm could send an event (swap 2 things) and then go on and issue more events. If the view thread is too slow, it could possibly swap the wrong data points. What needs to be present in the animation system to prevent this or to control it?
• What is the difference between Zeus and Balsa?
• Under what conditions would the ability to change underlying data from within a Zeus animation actually be useful?

About Anim:

• Does the Anim approach of glueing together various tools scale to more complex animations or is a monolithic application desired?
• "Movies are nice, but stills are much easier to distribute widely." The Bentley and Kernighan paper also makes a point about stills being better for publishing, pondering over and discussion. Aren't these points becoming less and less of an issue?
• The Anim system repeatedly claims it is a 'base' system. The output is crude, the input is made by an independent program, etc. They're claiming that this makes it easier to use. However, a user still initially annotates his/her program and adds an animation on according to this annotated data. This seems as complicated to learn as the Balsa, Smalltalk systems we read about earlier. Isn't Anim about as complicated to use but with less features?
• What, if any, advantage does Anim's use of 'stills' have over stopping the movie on a single frame and performing a screen capture to a file?
• In Anim, will it be easier for the reader of the script to see strings as labels of objects instead of numbers?
• Does the increased speed in Anim movie development make it more useful in debugging? The paper seems to imply so. How could this be further improved? Interpretation often helps speed up program development. Could an interpretation animation system be helpful?
• Would it be possible to make a 'history still'? This might have in other stills behind the current one, possibly in lighter color, in order to better convey the progress of the animation.
• Anim uses Sed and Awk and other UNIX tools to make animation easier than having to program C. For people who aren't experts in these tools, isn't is actually harder?
• Anim is designed as a simpler system that is easier to use. Discuss what abilities and uses of these abilities are lost in this simpler system as compared to the previous systems we have been reading about.
• Kernighan and Bently bring up the point about a minimum set of features needed for an algorithm animation system. What are those features?
• The idea of smooth animated transitions has been mentioned in several algorithm animation papers that we have read, yet the simple Anim system contains no facility for this. Do Anim animations suffer from this lack?

Other:

• Compare/contrast the ways in which Zeus and Anim make use of multi- view capabilities in creating algorithm animation, including functionality, implementation, and effieciency.
• From the set of algorithm animation papers seen so far, it seems to me (although each has its own specificity) that there are a lot of similarities. Is the field of algorithm animation completely defined or is it still possible to do some major improvement?

Extra comments by one particularly inspired student:

My main question about this paper is: who would use ANIM? In general, the purpose of software visualization seems to be threefold:

• Debugging
• Presentation
• Teaching

So, would the programmer use it for debugging? Since the features in ANIM are very crude, only the simplest algorithms could be animated. For more sophisticated algorithms, extensive work would be required by the programmer to get a good representation of the algorithm. Clearly, you do not want to have to do all this extra work to debug the algorithm. Furthermore, since the tools provided by ANIM are fairly low-level (how do you get a smooth animation of two bars being swapped?), you might as well use X or some other portable graphics library.

Would ANIM be used to present algorithms? Here, I use the word "presentation" to mean something inbetween debugging and teaching. For example, you may want to present an algorithm for members on a programming team, or project leader(s). These people may already be familiar with the algorithm, and the presentation is used to more clearly present how the algorithm performs on some set of data. Again, most algorithms that require visualization to be fully comprehended are in general fairly complex. ANIM may be good for bin packing and sorting, but it would be painful to use to visualize dynamic trees, data flow animations, OS data structures and algorithms such as process queues/scheduling, and 3D visualizations (e.g. object intersection). Also, for simple animations, it is often easy to visualize the algorithms yourself with a standard graphics library.

What about teaching? For this, it is often important that the images in the animation are aesthetically pleasing (nice colors and shapes), and also that the animation is smooth. Aditionally, redundant information (e.g. use both colors and shapes) is often useful to clearly point out what is going on in the algorithm. It seems that ANIM is too crude for this task, and there are many other similar packages that do a much better job at this.

Given enough time, I could easily refute all the arguments the authors present on page 14.

Another question concerns "inbetween states". This doesn't seem to be provided at all unless the programmer explicitly generates these pseudo states. According to some definitions, ANIM really doesn't do algorithm animation. With a few more primitives, this could've been handled, and I am curious as to why this was not done.