- Membership
- Publications
- Meetings
- Competitions
- Community
- Programs
- Students
- High School Teachers
- Faculty and Departments
- Underrepresented Groups
- MAA Awards
- MAA Grants

- News
- About MAA

This section discusses the complex design issues encountered when creating the Character Table web service, a project initiated by the second named author. [*The project link no longer exists. Contact the author for more information. Ed., 12/13/04.* ]

A great deal of information about a group can be gleaned from the character table, while character values are needed in many applications of group theory, for instance in computing non-abelian Fourier transforms used in statistics. Other applications are in physics, crystallography and chemistry where low dimensional group representations are of especial interest since they control the ways in which a group might appear as the symmetries of a physical system.

The computer algebra system GAP contains a powerful implementation of the Dixon-Schneider algorithm for computing the character table of a concrete group, given for instance by permutations, and also a very large library of known character tables, including all those in the Atlas of Finite Simple Groups. The format of the tables is derived from that used in the Atlas, and is described in detail in the GAP documentation. The Dixon-Schneider implementation draws on all of GAP's general group theoretic machinery, and also on its capabilities in linear algebra and finite fields.

The aim of this project was to make GAP's character tables available on the Web to researchers outside the core of computational group theory who don't want to spend the time downloading and installing GAP and learning its syntax.

The Web pages have two types of input. You may enter a list of permutation generators for the group whose character table you wish to retrieve, or simply the name of the character table. When the `go' button is pressed, a new browser window is opened in which the character table is displayed.

This application required two attempts to write. In the first attempt, the applet in the client's browser directly accessed the compute server creating a group in OpenMath, and retrieving its character table in OpenMath. Then it called on a MathML rendering engine to display the character table in the browser in a Swing table.

The problems with this implementation were twofold. Firstly, because it accessed the server and session classes directly using Java RMI, it depended on having an implementation of RMI in the browser's JVM which Internet Explorer 5 doesn't have. The second problem was that rendering the character table in the applet made use of the PolyMath OpenMath phrasebooks, an XML library, WebEQ -- a MathML rendering engine and Java's Swing libraries which meant loading several megabytes of jar files along with the applet into the client's JVM, making it very slow to load on an Ethernet connection, and virtually impossible over a 56k dial-up connection.

The solution to these problems reflects the reality of the Web at the moment and not the possibilities for the future, however it has proven that the Web is already a feasible medium for delivering dynamically generated mathematical content.

Firstly we scaled back our aspirations for presentation from MathML embedded in a Swing table to a choice of HTML or XML/OpenMath in case the user wants to paste the object into other applications. MathML rendering will be feasible once browsers have MathML rendering engines built in, rather than having to load rendering classes across the internet. This is already realized in the experimental browsers Amaya and Mozilla but is not yet in the mainstream browsers Netscape and Internet Explorer.

Even with our retreat from MathML, the XML library was required to render the character table, so we decided not to render it in the browser but in a servlet on the server, where the XML libraries were already installed. Further, the default jar files for the PolyMath Java Library are unnecessarily bloated for simply representing permutations, so the permutations were represented in the applet as Java vectors.

In the following paragraph we describe the dataflow, which is complicated by the need to minimize the amount of code which is transferred to the client side. However, we feel it is justified given a reduction in code transferred from several megabytes to under 20 kilobytes.

The applet stores the permutations on the server using an HTTP proxy to an RMI accessible hash table (this functionality is built into JavaMath). Then the servlet converts the vectors into OpenMath represented permutations, constructs a permutation group as an OpenMath object, and sends that to the GAP session to compute the character table. The character table is returned to the servlet as an OpenMath object which the servlet then renders according to the user's choice.

The code for this web service may be inspected at the Sourceforge CVS repository.

Alan Cooper, Stephen A. Linton, and Andrew Solomon, "Constructing Mathlets using JavaMath - Server Interactive Web Pages II," *Loci* (December 2004)

Journal of Online Mathematics and its Applications