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:
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:
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.
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 nm + n - 1 for n from 100 to 1000 and m from 2 to 10. It is clearly not the intention of Factoris to support such activities, since a direct use of PARI/GP with a small loop would give them the result within minutes. However, the fact that these people prefer spending so much time on Factoris suggests that they would have to spend more time and effort finding, installing, and learning to use PARI/GP directly. Therefore we are not discouraging people from using Factoris (and other online tools) in such an intensive way.
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 x2+1 or x1/2, respectively.
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 TEX-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 TEX-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.
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.
The functioning of the interface is similar to that of PARI/GP.
The functioning of the interface is similar to that of PARI/GP.
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.
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.
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 x3, 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 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.
The server can detect situations such as
At the end, it attributes a score to the user, which depends on the efficiency of the questions asked.
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.
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 are several factors that limit wide distribution of such a script:
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.
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.