DPVC (CV/Research/StageTools) [Prev][Top][UpUp][Up][Skip][Next]

Design Philisophy

It should be clear from the tutorials, and the paper describing StageTools, that there are several things that make CenterStage different from other mathematical packages like Mathematica and Maple. The most important of these are the ability to link input devices like sliders and check-boxes to values in the objects being displayed, and the ability to link one object to another.

The first of these means that when the user changes a value, the objects update automatically. This makes manipulating the parameters of the object very easy, and removes the need for the user to know complicated commands in order to see the results of his changes. For example, students can be presented with a demonstration that allows them to concentrate on the mathematical effect of their changes, rather than on the syntax and programming issues involved in making their changes.

The second of these makes it easier to specify certain types of objects, for example a tube around a curve. The author of a CenterStage demonstration does not need to work out the parameterization for the tube itself, but can simply describe the base curve and the cross-sectional shape of the tube; CenterStage does the rest. Additionally, if the curve changes, say due to a change in a slider, then the tube will update accordingly. This helps to maintain the natural connections between the various objects. The main paradigm of programs such as Mathematica and Maple is an algebraic one; the underlying idea in CenterStage is to treat the objects as having geometric, not just algebraic, content.

During the development of StageTools, certain basic decisions had to be made, like what language to use. An interpreted language was chosen because this offered several advantages. It makes prototyping and development easier, and avoids the machine-dependencies inherent in compiled code. It would make installation easier for users, as there would be no compilation necessary, with its associated need for libraries and other tools that makes installing new software a complicated process. It would make the resulting program more dynamic, in the sense that new code (e.g., new object classes) could be loaded in without recompiling the program.

The trade-off, of course, is that a compiled language offers superior speed, but the decision was made to sacrifice some speed for greater flexibility. The original need for StageTools was to make animations for the web, so the speed of generating a frame was less crucial, as it would not impact the final movie. It was only later that it became clear that CenterStage was also suitable for interactive work, especially in light of the recent explosion in processor speeds. Of course, converting the StageTools modules to a compiled language would give a vast speed improvement. This is a substantial project that is unlikely to occur in foreseeable future.

The next decision was which language to use. At the time, there were two candidates: Perl or TCL/TK.1 While Perl was a more sophisticated (and faster) language, TCL/TK was the obvious choice for several reasons: first, its TK library allowed for the creation of the user-interface elements (like sliders and type-in areas) that StageTools required, while Perl had no such ability; second, TCL was designed as a tool language to be incorporated into larger projects, so after the prototyping was done, portions of the code could be compiled into it for improved speed; and finally, TCL is extensible in the sense that user-defined procedures automatically become commands in the language, so the language can be customized to suit any needs. This makes it possible to define commands like Domain and Function for the Surface object without having to write a separate parser; one simply defines the procedure to be executed by these commands and pass the entire object-definition script to TCL to be executed as TCL commands. This has the advantage of making a fully functional programming language available in the definition scripts as well. The user can include if-then or looping statements, set and use variables and arrays, and even read files or produce output in his definition scripts, all without any additional programming required in developing StageTools. This flexibility has turned out to be very useful when CenterStage is used to produce complicated objects.

A disadvantage of picking TCL/TK was that it did not have an object-oriented programming model at the time,2 so StageTools includes an object-oriented programming layer on top of TCL.3 This is an additional speed trade-off, but has been well worth it in terms of programming flexibility. The various geometric object types (like surfaces and curves) are implemented through corresponding objects at the program level. Specialized versions of these geometric objects (like ruled surfaces or tubes around curves) are subclasses of the basic object classes at the program level. This makes it very easy to add new classes of geometric objects, as they will inherit all the important functionality from the parent class.4

Were this project to be started today, rather than in 1994, some of these decisions might have been different. For example, it would be wonderful to have a CenterStage-type program written in Java that could be included as an applet in a web page for use by students on a homework or lab assignment where they work experimentally with some mathematical object. Now that Java has a 3D graphics library, it would be possible to write a Java-based replacement for Geomview that would be sufficient for these needs.

Some would ask why it was necessary to write these programs when there are other mathematical packages such as Mathematica and Maple. After having gone through the tutorial and read these materials, the answer is probably clear at this point. First, these programs do not have interactive input controls (sliders, and so on). Second, they use an algebraic rather than a geometric approach, so the linking of one object to another is much more ad hoc. Third, the graphics in these programs is not very interactive. For example, in Mathematica, in order to rotate a 3D object, one must specify a new viewpoint by hand or through a cumbersome control panel, and then must recompute the graphic; this is not interactive. In Maple, objects can be rotated interactively, but in order to change the object being displayed, one must enter commands to create an entirely new graphic; this is not very dynamic, either.

Another question some may ask is why pick a unix platform rather than a Mac or PC for this project? Aside from the fact that Geomview is only available under unix, there are other reasons. One must recall that in 1994, a 33 Mhz PC was considered reasonably fast, and hardware-based graphics acceleration was expensive. Now, 800 Mhz machines are common, and 1.4 Mhz clocks are available. Then, Microsoft Windows was still at the sub-standard version 3.1,5 and the Mac OS had only just become multi-tasking with version 6. While things were improving on these platforms, they were not yet ready for serious graphics development. Also, the TCL/TK language, chosen for its flexibility and user-interface capabilities, was not available on microcomputers at that time.


Note that Java was just being developed by Sun, and had not yet been licensed by Netscape and Microsoft for their browsers. Its future was not yet clear, and in any case, it would not have interoperated well with Geomview at the time.


This is not entirely true, as ITCL was then in its early stages of development. Its features were unsatisfactory at that point, and we did not want to have an additional installation requirement when StageTools was distributed.


This could have been distributed as a separate product, but there are now half a dozen other similar systems available, so it did not seem necessary. Most of these try to mirror the style of C++ or other established OO language, while mine was designed to fit the TCL language model more closely.


You can look at the class definitions in StageTools/module/CenterStage/Class. The ones that begin with "basic" are the ones that do the actual work of the object (the non-basic ones add the information needed for the definition script and for the CenterStage GUI to maintain an instance of the class). The subclasses such as basicTube are quite small, since all the hard work is done already in the basicSurface and basicSurfaceFromCurve classes.


The first usable version of Windows, in my opinion, was Windows 95, which didn't arrive until 1996.

[HOME] Davide P. Cervone's web pages
Created: 08 Sep 2001
Last modified: 09 Sep 2001 23:15:09
Comments to: dpvc@union.edu
[Next] Design Issues
[Skip] Electronic Communication of Mathematics
[Up] The StageTools Geometry Package
[UpUp] Software Development
[Prev] Obtaining StageTools