We describe in this paper the *WWW Interactive Mathematics Server* (WIMS), designed for supporting intensive mathematics work via the Internet with server-side interactivity, accessible at http://wims.unice.fr. The following main features of the system are described:

- A modular design allowing applications and software interfaces to be created and maintained independently from each other.
- Existing interfaces for software packages, including
*Maxima*,*MuPAD*,*PARI/GP*,*Octave*,*Gnuplot*,*Povray*, and*Coq*(proof assistant). - Dynamic rendering of mathematical formulas and animated graphics.
- A structure of virtual classes, including mechanisms for automatic score gathering and processing.

In a future paper, we will discuss technical choices and details involved in the design of the system, including language design, session control, security measures, and anti-cheating mechanisms.

We describe in this paper the *WWW Interactive Mathematics Server* (WIMS), designed for supporting intensive mathematics work via the Internet with server-side interactivity, accessible at http://wims.unice.fr. The following main features of the system are described:

- A modular design allowing applications and software interfaces to be created and maintained independently from each other.
- Existing interfaces for software packages, including
*Maxima*,*MuPAD*,*PARI/GP*,*Octave*,*Gnuplot*,*Povray*, and*Coq*(proof assistant). - Dynamic rendering of mathematical formulas and animated graphics.
- A structure of virtual classes, including mechanisms for automatic score gathering and processing.

In a future paper, we will discuss technical choices and details involved in the design of the system, including language design, session control, security measures, and anti-cheating mechanisms.

We describe in this paper the *WWW Interactive Mathematics Server* (WIMS), a project aimed at a systematic approach for providing Internet-accessible mathematical computations.

Internet-accessed mathematical computations present several advantages over locally installed mathematical software. With interfaces based on the html protocol, many common computational needs can be carried out by the user without having to first learn the syntax of a particular software system. And software installation and maintenance costs are considerably reduced.

User-friendly access to mathematical computations also means the design of computer-generated mathematical exercises with sophisticated analyses of answers. When an Internet server generates the exercises and processes the answers, analyses of students' progress can be easily achieved, with data and results well-protected against cheating, a feature otherwise hard to realize by locally installed software.

To obtain a high degree of mathematical sophistication, the basic design concept of the WIMS project is server-side interactivity via http protocol, with a modular structure at two levels, which makes the system easily enhanceable.

On the one hand, each application (exercise or tool) under the system can be independently created, modified, or removed, allowing the system to host a large number of such applications. On the other hand, the system calls various mathematical software packages (e.g., numeric or symbolic computation, visualization, proof assistant) as background engines, with an independent interface designed for each such package. This provides an easy and versatile way for WIMS applications to make use of the power of these packages.

As a result, we can create applications with unique features for web-based mathematics -- interactive theorem proving, animated visualization for user-supplied expressions, exercises with multiple correct answers or multistep answers, and so on. And in a few domains, such as first-year linear algebra, where enough applications have been developed, the system is ready for serving mainstream educational use.

Design choices, capabilities, shortcomings, and unsolved problems of the system are all discussed in the paper. Most technical details are omitted in order to keep the paper within reasonable length and readability. Interested readers can refer to WIMSdoc or the source code for these details. A few other topics are also omitted here, such as facilities for user contributions.

The word *interactive* is somewhat ambiguous when applied to the web environment, for the html format is already interactive: You click on a link, and you see the page change. So here we usually use the word *interactive* to mean that some computer program is involved to process users' clicks. In this sense, there exist basically two approaches.

- First, there is client-side interactivity: Programs, usually Javascript or Java applets, are embedded in the html page, sent to the client, and executed on the client computer by the browser. For example, the site Interactive Mathematics Miscellany and Puzzles contains a large number of such pages.
- Second, there is server-side interactivity, in which a program installed on the server site processes the client requests. Examples of this method include The Integrator or Mathserv.

Both approaches have their advantages and inconveniences. For server-side interactivity, the main *advantage* is the power of computation that can be provided by sophisticated background computational software packages. Such computational power is often difficult to achieve by Java applets sent to the client. And the main *disadvantage* is delay of response, especially when the connection is of limited bandwidth. WIMS is based principally on server-side interactivity, although some of its applications may also incorporate Javascript or Java applets, in particular when high-speed response is needed. And it is specially designed to support mathematical applications.

In order to take full advantage of server-side interactivity, WIMS incorporates interfaces for many mathematical software packages. It may even call several packages in a chain to compute one user request. As a result, we have been able to create applications which can make sophisticated computations, while at the same time being easy to use.

Because of the importance of practice in mathematics learning, we have emphasized online exercises. Use of mathematical software allows generation of random exercises -- for example, in Visual Gauss we generate random unimodular matrices based on LU-decomposition. It also allows computed analysis of user answers -- for example, in Bases there are infinitely many good answers (bases), so each answer is analyzed by PARI/GP instead of being compared with a prepared database of good answers. Software originally designed for local interactive use can also be adapted to power step-by-step exercises -- for example the use of Coq (see Page 5 for detail) in Logicoq.

Mathematical software is also used to power online computational or visual tools designed to provide online help for the exercises. But these tools can also be used as stand-alone ones.

These online tools in WIMS are not intended to replace traditional use of mathematical software packages by power users to carry out complicated computations via programmed scripts. Rather, WIMS is intended for "casual" users who want to carry out only "simple" computations, for which it is often not cost-effective to learn the syntax of the software for just a few such computations. In fact, for security reasons, we avoid letting the user directly type in source lines of a computational software via WIMS. The system security also disallows computations requiring a long execution time.

On the other hand, web user interfaces can be made much more user friendly for the computations they support, and it is possible to create applications on WIMS combining the computing power of several different software packages.

Of course, this design goal of WIMS does not stop people from using it in other ways. For example, we have regularly seen users spending hours or even days on Factoris to factor series of integers such as *n ^{m}* +

The center of the system is a cgi program, wims.cgi, written in C, whose location is the unique entry point of the server. It processes user requests arriving from http connections. These requests may contain parameters, which will be captured and interpreted by wims.cgi.

Each application under the system is an independent unit, called a *module*. Modules are written in a specially designed scripting language to be interpreted by wims.cgi. Inter-module communication is achieved via http links. Many capabilities of the system are available to modules via special commands in the scripting language, so that these capabilities can be enhanced or upgraded without modification at the module's level, as long as backward compatibility is respected.

Each module under WIMS resides in a separate directory, which also contains a number of files for different purposes, written in the scripting language. A typical user request to WIMS should contain information for the name of the module requested, for which wims.cgi will then read the files in that module's directory and interpret them. The result is an html page generated by wims.cgi and sent back to the user.

Our principle is to let all sophisticated mathematical computations be carried out by exterior programs, in order to gain maximal power and versatility with minimal cost of development. Thus wims.cgi can carry out only very basic computations by itself. When needed, the module's writer can use a special command to execute an exterior program for mathematical computations or visualizations. An interface to this program is then called by wims.cgi, which prepares the parameters, executes the appropriate program, and filters the output of the latter to make it directly usable by subsequent commands in the module.

The number of programs that can be executed to process one user request is limited only by the server resources. For example, in the module Factoris, a user-submitted expression is first sent to PARI/GP for a check of syntax consistency. Then the number of variables in the expression is computed. For integers or one-variable polynomials, PARI/GP is executed again to factor it. For multivariate polynomials, Maxima is called for factorization.

The home site of WIMS is freely accessible to all, and it contains a list of publicly available mirror sites. Online help pages and technical documentation can also be found there.

The source code of the system (server and modules) is freely downloadable from http://wims.unice.fr/download/wims, distributed under the GNU General Public License. At the current stage, the system is available only for Linux, with no immediate prospect of porting it to other operating systems.

Although it is possible for anyone to work on a remote WIMS server through the Internet, we recommend local installation if intensive work is planned, due to possibly important delays caused by network saturation. The installation of WIMS itself is relatively easy, but installation of support software packages is sometimes more complicated.

The types of user input WIMS can accept are limited by the http protocol. They include multiple choices (menus), numerical data (real, complex, or others), text data (equations, expressions, matrices), plane coordinates (clicking on a picture). Multiple input data can be contained in one user request via the html form protocol. Input of geometric objects other than points is not supported by the ordinary html standard. Therefore this can be achieved only by text data or by using Java applets.

The capability of WIMS to process user input is limited only by that of the various software packages interfaced by it. In particular, unlike many other Internet exercise systems where user answers are merely compared with stored standard answers, answers to exercises under WIMS are mathematically analyzed, providing much more freedom for exercise design. For example, we can create exercises whose correct answers are not unique, as well as exercises with multistep answers. A sophisticated error analysis mechanism can also be built into exercise modules, helping users to understand the reasons for their failures.

Most exercises under WIMS incorporate random parameters (numerical, functional or configurational), so they are highly non-repetitive. Also, they are usually configurable by several configuration parameters, intended for teachers to set up the level of difficulty of exercises for their students (see Page 7).

Users through the Internet are often not very strict about syntax rules when they input mathematical expressions. For this reason, WIMS has a mechanism to automatically correct common syntax "errors" whenever there is no ambiguity about the intention of the user. For example, `2x` is corrected to `2*x`, `sint` is corrected to

`sin(t)`, `(x - 1)(x + 1)` is corrected to `(x - 1)*(x + 1)`, etc. In ambiguous situations, such as `x2+1` or `x^1/2`, a warning message prompts the user to enter `x^2+1` or `x^(1/2)`, if the intended expression is `x ^{2}+1` or

In any case, whether to apply this correction mechanism or not, and how, is decided by individual applications, according to context.

WIMS has an advanced mechanism to allow dynamic and efficient insertion of mathematical expressions into the output page. Some programs, such as Latex2html, process a source file and produce a static image file, referenced by the resulting html file, corresponding to each mathematical expression. WIMS, on the other hand, processes mathematical expressions differently according to the content of the expression. If, for example, the expression is a polynomial, then simple html tags can be used to render it. Otherwise image files can be generated "on the fly" to represent the expression. In this way, WIMS supports T_{E}X-rendered expressions that are not fixed.

When combined with the error-correction mechanism (see 2.1) for input, this becomes a very convenient means for mathematical communication on the Internet. This capability is implemented in the discussion forums under WIMS: The user can write mathematical formulas freely and have these formulas automatically rendered correctly for viewers. The interested reader may look at the WIMS Comments Forum for this feature -- click on "Unformatted view" under a message to see the suggested input syntax, or compose a message to see how it works.

When MathML becomes a reality, WIMS will be ready to automatically recognize MathML-capable browsers and send them MathML-coded mathematics formulas instead of T_{E}X-formatted image files.

WIMS can also generate animated graphics "on the fly." Three programs can be used for this purpose: Povray, Gnuplot (see Page 5), and a drawing program included in the WIMS package. While all three can generate animated graphics dynamically, the most spectacular results are achieved with animated ray-traced surfaces, which theoretically can be drawn online. However, current computing hardware is not powerful enough to generate high-quality animation sequences with reasonable delay times. This capability will automatically become available once the server is installed on a more powerful computer.

As an example, we have put up a small gallery of animated surfaces generated by WIMS. They were produced after widening resource restrictions on a private installation of WIMS.

The number of simultaneous accesses is limited only by the server resources. This limit varies according to the speed of the server and the network connections, as well as the nature of the activities. For very intensive activities, such as factorization of large integers or generation of ray-traced images, only a few accesses are enough to saturate a server.

To illustrate a more ordinary situation, the home site of WIMS is actually a bi-processor Pentium III running at 500MHz, with 256M DRAM. We have been using it for everyday teaching in Université de Nice - Sophia Antipolis. The load often goes up to more than 60 simultaneous connections, by students working on exercises of different kinds. In such situations, the hardware load usually goes up to around 40%, which seems to indicate that there is still plenty of room for more load. However, in one situation, when all 60 student stations were working on computation-intensive exercises, the server was at near-saturation (200% average load).

WIMS allows site managers to set up client priorities. When the work load goes up, connections from low-priority sites will be refused, leaving only priority connections.

In principle, WIMS can interface with any program allowing batch mode execution. The main restriction is that software with restrictive licenses should not be freely accessible on the Internet, so modules that must call restrictive software should put access restrictions on them. Partly due to the distribution policy of WIMS, we do not have interfaces to such restrictive software yet, although many of such programs are easily interfaceable.

Software interfaces in WIMS are independent from the kernel and independent from each other, so they can be added, removed, or modified without affecting the global functioning of the system. One of the basic functions of the interfaces is to serve as a security barrier. For this reason, only interfaced programs can be executed by WIMS.

The following interfaces are currently available.

- PARI/GP is an excellent arbitrary-precision package for computations not involving transcendental functions.
The header of PARI/GP output is automatically stripped off by the interface. For the rest, each line of the output corresponds to a line in the calling parameter. Although this output can be directly inserted into the html page sent to the user, it is usually processed and formatted so that the user sees beautified mathematical expressions.

- Maxima is now the basic symbolic algebra system upon which WIMS relies. Its greatest advantage is being completely free (GNU). However, it is not as strong as many other symbolic algebra packages when difficult integration is involved.
The functioning of the interface is similar to that of PARI/GP.

- MuPAD is a symbolic algebra package whose copyright holder allows use on the Internet with interfaces that do not give direct access to the full power of the software.
The functioning of the interface is similar to that of PARI/GP.

- GAP is a powerful package for manipulation of algebraic structures. For the time being, there are two WIMS applications (Permgroup and Smallgroup) that make use of this package. These compute, respectively, finite permutation groups and finite groups of orders up to 255.
- Octave. A preliminary interface for this numerical package exists, but no module makes use of it yet.
- Gnuplot, a popular plotting program, is accessed by WIMS with a special interface, part of which is directly incorporated in the kernel.
Several incompatibilities concerning mathematical expressions are fixed by the interface: for example, "^" is translated to "**", and integer fractions such as "1/2" are translated to "1/2.0" (to avoid having the result of an integer division be 0).

The interface includes an adaptation for plotting animated sequences by adding a few extra parameters. This is done by asking Gnuplot to plot images, then putting these images together into an animated gif file. Performance is reasonably good, as animations with acceptable quality can be generated in a few seconds.

This program is included in standard Linux distributions.

- Povray, a popular ray tracing package with direct support for animation.
The application Polyray makes use of this package. It appears that there is no danger in allowing direct user-supplied source for Povray, so Polyray has a text field for user input.

- T
_{E}X. The interface to T_{E}X is transparent to application writers, as WIMS has commands that can selectively use html or T_{E}X rendering of mathematical expressions according to the context. - PostgreSQL is an SQL database engine that used to be the standard database manager for WIMS. In the current version, it is used only to manage the applications database, and it is planned that, at some future date, WIMS will no longer depend on it. A basic reason for this change is that WIMS is now developing search mechanisms which are more versatile than the standard commands of SQL.
- COQ is a proof assistant package built upon CAML and designed for interactive use. At each proof step, a status is printed, including new goals to prove and hypotheses for the principal goal.
A WIMS module using this package should support step by step operations. It should store the whole command history in a variable, and at each step, the last command is appended to the command history, then the latter is fed to the interface for Coq. The interface captures the last status printed by Coq, and splits this status into two return data, one for the goals remaining to be proven, and the other for the hypotheses for the principal goal.

Another function of the interfaces is to improve inter-software communication. Each software package comes with its own language syntax, which differs from one package to another. Even common mathematical functions have different names, so, when necessary, alias definitions and expression translations are built into the interfaces.

For example, Gnuplot uses `x**3` to denote `x ^{3}`, which is not recognized either by PARI/GP or by MuPAD. To make mathematical expressions directly chainable from program to program, routines have been inserted in the respective filters to translate syntax used unambiguously by other programs into the syntax proper to the interfaced program. Similarly, function names or constant names that are commonly used but not recognized by the interfaced programs, such as sh instead of sinh, are defined in the interfaces.

WIMS offers great freedom in the design of modules. As a result, a wide variety of applications of various aspects are now available. Here we discuss some of them as examples.

- The most popular activity on the WIMS server seems to be Shifting Puzzle, partly because no mathematical sophistication is needed to play with it. This is a typical step-by-step interface: It presents a scrambled m×n puzzle, and the user can successively shift a row or a column of pieces, until the puzzle is recovered.
The only mathematically nontrivial part is the generation of the puzzle. For example, in the 3×3 case, the combination of shifts can generate only even permutations (all of them). Therefore, in the initial scrambling by the server, only even permutations are generated, so that every puzzle presented to the user is solvable.

- Another step-by-step example is Visual Gauss, which can generate linear systems or matrices over various coefficient rings, including finite ones. The user can make successive modifications of rows by clicking or by returning forms. Since PARI/GP (see Page 5) is involved in all of the computations, a change of coefficient ring amounts to some minor changes in the script sent to PARI, controlled by a parameter.
- The system also allows "interactive" exercises, in which the user is encouraged to ask questions of the server in order to solve a problem. Linear system dialog is such an example. The exercise
*Number of solutions*is in fact quite complicated: The next question to ask may depend on the answer to the last question, and there are several different ways to get the necessary information, with different levels of efficiency.The server can detect situations such as

*pure speculation*-- where the user does not have enough information to determine the answer to the problem -- or*unnecessary information*, such as the number of equations, which is not directly related to the number of solutions of the system.

At the end, it attributes a score to the user, which depends on the efficiency of the questions asked.

- Graphic functions is a classical multiple-choice exercise, but one that generates interest by constructing both the question and the choices as random graphics. There is no database of pictures behind the exercise: Every curve is plotted
*on the fly*by Gnuplot, using randomly generated functions, taking care that no ambiguous situations (in which several choices may look good) are generated. Except for such technical restrictions, the functions are as random as possible, so that in practice no repetition will occur.There are several exercises of the same style. Interested readers can search for the word

*graphic*on the WIMS site to get the complete list. - Where a computational tool is needed, WIMS can allow users to make common computations without the need of installing and learning the corresponding software packages. The tools Function calculator (limit, derivative, integral, Taylor, root, extrema, etc.), Matrix calculator (determinant, rank, characteristic polynomial, eigenvalues and eigenvectors, etc.), Factoris (factorization of integers and polynomials), Tracés animés (plots of curves and surfaces), and Polyray (ray-traced algebraic surfaces) are examples of this feature.
A comment about the root/extrema search under

*Function calculator*: Behind the simple user interface -- click on an apparent root or extremum in the picture, and the root or extremum is found and computed to arbitrary precision by the software -- several programs are called in sequence to compute the answer: PARI/GP for roots, Maxima for symbolic derivatives, and Gnuplot to plot the point. A similar mechanism can also be found in D-int for computation of numerical double integrals. - There is another advantage of online tools, less known but not less important. Take the example of Animated sequences, a special tool designed for graphical illustration of convergence of functional sequences or series, and quite useful for a teacher of, say, Taylor series. I have no doubt that I am not the first to think about such an application. However, this kind of thing is too special and too complicated for general-purpose mathematical software to carry a single-command implementation. So anyone wanting to construct this application would have to write a script or program, which might turn out to be quite complicated.
There are several factors that limit wide distribution of such a script:

- the popularity of the software under which the script can run,
- the specificity of the purpose, and
- the limits of communication -- there are thousands of scripts, and a user cannot test them all -- so how can you convince him or her that yours can do the job?

The online environment is particularly suited for such special-purpose applications: No distribution of the script is needed, and any interested person can test it or use it immediately online. Although WIMS contains some applications that may be considered "special purpose," it is still at its very beginning with respect to the huge potential of development in this direction.

- As a last example, we present the recent addition Pathfind, which employs an algorithm searching for the shortest path, a problem of exponential complexity with respect to the number of points. An initial implementation of a naive algorithm in PARI/GP stops at less than 8 points. An improved algorithm, implemented in C with serious optimization, gives the current result -- 16 points open for the public, but one can go up to 20 points with a bit more delay. When the C program is finished and compiled, it is put into the bin directory of the server, and the module
*Pathfind*can execute it, so that the computation is accessible by the general public.This illustrates another interesting potential use of WIMS: The best way to publish a special-purpose algorithm is online execution. The distribution of source code is limited by many factors just as in Example 6: adoption rate of the language under which the algorithm is implemented, limits of communication, and users' willingness to compile.

On the other hand, a naive online execution chained by a simple cgi script may bring considerable security risk to the server, so a system like WIMS, having several layers of security protection, is necessary for such online executions. (The security issues will be discussed in another paper.)

WIMS is designed to support intensive classroom applications. To this end, it incorporates a structure of virtual classes. A virtual class under WIMS can be created and managed entirely online by the teacher (supervisor) of the class. Students can then be registered in the virtual class, either by the teacher or by themselves, with the registration mode definable by the teacher.

A user can connect to WIMS in one of three ways: as anonymous visitor, as the teacher of a virtual class, or as a student. The first is open-access, while the other two are protected by passwords.

The content of a virtual class is a number of worksheets, which are created and maintained online by the teacher. Each worksheet contains a number of items, and each item is the address of a WIMS module, which may be an exercise (for which the teacher has determined the difficulty level), an online tool, an online lesson text, or other.

The design of the system requires that the teacher of a virtual class takes responsibility for choosing the exercises for his or her students, as well as determining the difficulty level of the chosen exercises. For this purpose, pages sent to virtual class teachers contain special links. The teacher has only to click on these links, in order to add a chosen exercise into a worksheet. The difficulty level and configuration of the exercise added to the worksheet will automatically be set to that of the exercise containing the link.

When adding an exercise to a worksheet, the teacher can also set up the number of points each student is required to make, as well as the weight of these points in the computation of averages. Sample worksheets are also created and can be inserted directly in virtual classes, helping teachers to make their choices.

Student who log in to the virtual class are presented the list of active worksheets. While working on the exercises contained in a worksheet, the scores they obtain are automatically gathered by the server. However, points exceeding the assigned number are discarded by the system, preventing students from gathering extra points by repeatedly working on one (easier) exercise.

Each time a student answers an exercise, the score and the resulting change in average are shown on the page. Experiments show that this instantaneous feedback is very efficient in inducing students to work hard.

In the current version of WIMS, a complete list of scores of a virtual class can be consulted only by the teacher. For each student and each worksheet, the system computes a score based on two numbers: the percentage of assigned work done and the average of individual scores (between 0 and 10). The computation depends on a formula according to a (modifiable) severity level determined by the teacher.

In principle, the system allows students to log in to the virtual class any time and from anywhere, to work on the assignments. Some people object to this possibility, because some students may ask others to log in, work, and get points for them, especially when the points are used in student evaluation. For this reason, teachers' pages include menus allowing them to change the score registration status of a given worksheet: open, close, or open for a selected number of sites. With this feature we can let students score only during monitored classroom sessions.

Each virtual class also has a discussion forum to host electronic discussions between teacher and students, or among students. Mathematical expressions can be inserted in a very easy way into messages within the forum (see Page 4).

All manipulations within virtual classes (for teacher as well as for students) are done online, via html links and forms. This is straightforward in most cases: For example, to create a new worksheet, the teacher can click on the link "create a new work sheet" in the teacher's home page. And online help pages are available at many places.

The least obvious manipulation is for the teacher to add an item into a worksheet. Usually the item is an exercise, and most exercises on WIMS accept various configuration parameters that vary the difficulty level in a very wide range. So, in selecting the exercise, the teacher not only designates the module but also sets the parameter configurations. In practice, this is done in a quite transparent way. Once a choice of configuration is made -- usually when a new exercise is generated -- a link "Insert into a work sheet" will appear at the bottom of the page. Clicking on the link brings up a form page allowing the teacher to determine insertion parameters (number of worksheet to insert into, number and weight of required points) and to insert the exercise.

We have made a large-scale use of virtual classes (400 students) at Université de Nice - Sophia Antipolis during the year 1999-2000. Practice shows that students usually have no difficulty getting used to the interface, and they start to work very quickly after registration. Some of them are also very quick in starting attempts at cheating -- and getting warned by the server.

Student behavior under this environment is usually quite different from that in a classical environment. They become very active, trying to find out the most efficient way to get points. When they have difficulty getting solutions to some of the exercises, the demand for help from the teacher present in the classroom becomes very pressing. When the teacher is not immediately available, discussions among students start quickly, with the most advanced helping those in difficulty. However, nobody can copy another, because everybody is working on a different exercise, and the difference in the question may often lead to radical differences in solutions.

In our setup, worksheets are installed days before the working session, to allow students to practice on them. However, they can get scores only during the work sessions, and only from computers within the classroom. With this precaution, the individual scores registered by the server are sent directly to the administration for calculation of each student's credit, and there have been no contests of the server-generated scores.