Automatic Translation of Computer Algebra Systems Worksheets

Transcription

1 Automatic Translation of Computer Algebra Systems Worksheets Lauri Eskor, Marina Lepp, Eno Tonisson Institute of Computer Science University of Tartu Tartu, Estonia Abstract There can be varying degrees of difference between the commands, syntax, etc., of computer algebra systems. Sometimes, translation from one computer algebra system to another is needed. As the languages of computer algebra systems are similar to programming languages, the translation techniques used in case of programming language seem to be productive. This paper focuses on syntax-directed translation where grammars have a central role. The area of commands is restricted to the commands useful for school mathematics. A prototype is developed for translating the worksheets of Maple, Maxima and WIRIS. Index Terms computer algebra systems translators grammars I. INTRODUCTION There are dozens of Computer Algebra Systems (CAS) available for users: Derive, Maple, Mathematica, Maxima, MuPADand WIRIS, to name but a few of them. Usually a user is adept at working with a specific CAS. However, in some situations it could be useful to transform commands or worksheets of one CAS into a form recognizable by another. The reasons for transformation could be personal the user replaces a CAS and would like to continue using the existing material. There could also be wider reasons a larger community may require a new CAS. For example, Derive was widely used in Austrian schools there were many worksheets, teaching materials and experienced teachers. Quite suddenly, Derive was bought up and development was stopped. It is possible that the new CAS is more or less compatible with the former CAS and using previously generated material is no problem at all. However, this is not usually the case and converting old worksheets becomes a time consuming manual labor. Considering that, an automatic translation system could be useful. As the languages used in most CAS are similar to programming languages, the methods used for compiling programming languages may be employed for translating CAS languages as well. The aim of this paper is to investigate, if using syntaxdirected translation could be a viable way for translating worksheets of different computer algebra systems. As different computer algebra systems have a great variety of features, we focus on a restricted domain the commands that are useful for learning and teaching school mathematics (for example, solving equations, investigating functions but also calculation of limit and integration). Maple [1], Maxima [2] and WIRIS [3] are examined as sample CAS. The section after the introduction describes the background and related works. The third section provides a brief introduction to translators and syntax-directed translation. Section 4 is about grammars of CAS. A prototype CAS-translator is introduced in Section 5. Some ideas for future work are expressed in Section 6. II. MOTIVATION AND RELATED WORKS Command is one of the main units in CAS. When a user enters a command the CAS returns with a specific answer. Typically there are several commands in a worksheet. There could be different terms used in different CAS instead of worksheet, e.g., notebook. Actually, a worksheet could contain, beside commands and answers, comments, drawings, layout information, and so on. Part of the information, for example, layout, could be very specific for the particular CAS. We focus on commands. CAS can have different ways of entering a command and expression, like palettes, menus or buttons we might see a nice two-dimensional form on the screen (see Fig. 1). Nevertheless, we use here only classic one-dimensional notation, such as limit(1/xˆ2, x, 0). Translation of CAS worksheets is useful if the user migrates from one CAS to another. The reasons could be very different, e.g., developer support has ended, decisions of the school authorities, and so on. For example, a country has a license of one CAS for all schools but the annual license fee turns out to be too expensive. Automatic translation could also be useful for researchers who analyze several CAS at the same time (some examples of such analyses are in [4], [5] and [6]). Furthermore, translation could be necessary for complex systems that use a CAS as a module. There have been several attempts to automate the translation of CAS languages. The prototype described in [7] seems to be most similar to our approach. It was developed for translation of programs and data from one language to another. The CAS under consideration were Macsyma, Maple and Reduce. The parser (based on yacc [8]), the scanner (based on lex [9]), the Figure 1. 2-D CAS input.

2 Figure 2. A translator. code generators, and so on, were used in the translators. The aim was to create an almost universal system but it was overambitious. (We have constrained ourselves to using only the limited domain of commands.) Other products translate from one particular CAS to another. For example, Mixima is a translator from Mathematica to Maxima [10]. It works as a module of Maxima and was written partially in Lisp. There are collections of synonyms for various operations in computer algebra systems. The Rosetta Stone for Computer Algebra Systems [11] contains information about more than twenty CAS. The use of more general formats, like OpenMath, XML, MathML, is a very compelling idea but, like the use of CAS as part of more complex systems (e.g., in [12]), it is not discussed in this paper. III. TRANSLATORS A program that can read a program in one language and translate it into an equivalent program in another language is called compiler. The term compiler is, first of all, used for programs that translate source code from a high-level programming language to a lower level language. If the source language and the target language are both high-level languages (and CAS languages are high-level), the program is usually called translator (see Fig. 2). There are many information resources available on compilers and translators. This section is based somewhat on [13]. The translation process consists of different stages. One could differentiate between analysis and synthesis. Analysis is divided to lexical, syntax and semantic analyses and provides an intermediate representation. During synthesis, the target program is composed from the intermediate representation. We focus on syntax-directed translation a technique that is grammar-oriented and centers on syntax analyses. Fig. 3 illustrates the model of the analysis stage of the translator. Scanner uses the source program and lexical rules and produces a stream of tokens. Parser uses the stream of tokens and syntactical rules and generates a syntax tree. Intermediate code generator generates intermediate code with the help of semantic rules. Rewriting rules are required to derive the final target code from the intermediate code. Figure 3. A model of the analyses part. Analysis is based on the syntax of the source language (syntax-directed translation!). Syntax could be specified as a context-free grammar and expressed by Backus-Naur Form (BNF) or Extended Backus-Naur Form (EBNF). A grammar describes the structure of language constructs by using production rules. There are different variants of EBNF the following example is based on the ISO standard for EBNF notation, where [] means an optional item, - and {} mean repeat 1 or more times, or 0 or more times, respectively, and the symbol, is used for concatenation (see [14]). number = {digit}- identifier = letter {letter digit} functioncall = functionname, "(" [parameterlist], ")" Creating grammars can lead to several difficult problems, where one production rule conflicts with another. One can use a more powerful parser to overcome these conflicts, but such parsers are more difficult to program and debug. Consequently, in order to build a translator we need to program a scanner, a parser, an intermediate code generator and a target code generator. First and foremost, we need the grammars of CAS (lexical rules, syntactical rules, semantic rules), which are discussed in the next section. IV. GRAMMARS OF COMPUTER ALGEBRA SYSTEMS To translate worksheets of different CAS we have to know the exact syntax of CAS languages. A formal grammar that consists of a set of rules, which describe how to form valid commands according to the language s syntax, would be extremely useful. While the syntax of different CAS is wellknown and widely described (for example, in CAS manuals), it is very hard to find grammars for CAS languages. It would be nice to have a grammar in some form for every language. We do not have this at the moment, but this is work that has to be done eventually. Syntaxes of different CAS could be very different composing a grammar could be easier in case of some CAS while it could be quite difficult in case of others. However, if we restrict the domain (for example, constrain it to school mathematics) then the goal can be achieved and grammars can be composed. As an example, we can compose a grammar for Maxima worksheet, where only three commands are available: finding limit, integrating and solving of equation. We use the notation of EBNF. worksheet = {command}- command = limit integrate solve limit = "limit", "(", expression, ",", variable, ",", expression, ")", "" integrate = "integrate", "(", expression, ",", term [",", term, ",", term], ")", "" solve = "solve", "(", expression, ",", term, ")", ""

3 term = ( "(", expression, ")" ) variable number unary = ["+" "-"] term mult = unary [ ("*" "/"), unary ] add = mult [ ("+" "-"), mult ] expression = add [ ("=" "<>" "<" ">"), add ] variable = character { character digit } number = {digit}- character = "a" "b" "c" "d" "e" "f" "g" "h" "i" "j" "k" "l" "m" "n" "o" "p" "q" "r" "s" "t" "u" "v" "w" "x" "y" "z" digit = "0" "1" "2" "3" "4" "5" "6" "7" "8" "9" The production rule worksheet shows that in this language there is a worksheet, which consists of one or several command rules. The rule command can be finding limit, integrating or solving the equation. The rules limit, integrate and solve define the exact structure of command with the help of other rules and terminals. Other rules describe terms, expressions, variables, and so on. For example, variable is defined as a word that begins with a lowercase letter, which is followed by zero or several lowercase letters or digits. Terminals are symbols, which appear only on the right side and are enclosed between the pair "". As we can see, definitions of terms, expressions, variable and numbers (even in simplified form) constitute a large part of grammar. This part describes how mathematical expressions can be composed and it is quite similar (maybe with small differences) for grammars of all CAS languages. Different CAS languages have different syntaxes for commands. The rules that describe commands would be different in grammars. For example, the rule limit in Maple grammar would be limit = "limit", "(", expression, ",", variable, "=", expression, ")", "" and in WIRIS grammar limit = "limit", "(", expression, ",", variable, ",", expression, ")" For the purposes of composing a grammar, we use onedimensional notation for input of commands (see Fig. 4) instead of the possibly more common two-dimensional notation (see Fig. 1). Figure 4. 1-D CAS input. V. A PROTOTYPE CAS-TRANSLATOR We have created a prototype CAS-Translator to try to translate worksheets from one CAS language to another. This version of CAS-Translator allows translating commands and worksheets between three CAS languages: Maxima, WIRIS and Maple. The domain of commands is restricted to school mathematics (including integrating and finding limit). The parser generator ANTLR (Another Tool for Language Recognition) [15] was used to create necessary parsers. ANTLR is a language tool that provides a framework for constructing translators and describing specific languages, can use grammars and rewriting rules to create the needed translation engine with minimal amount of programming. ANTLR uses a slightly modified version of EBNF, where production rules are described as regular expressions with the help of lexemes. Lexemes are defined inside of production rules with apostrophes or written in capital letters. Lexemes in capital letters are described as regular expressions. ANTLR allows writing semantic rules into grammar. We had to modify the grammar to be suitable for ANTLR. grammar Maxima worksheet : command+ command : limit integrate solve limit : limit ( a=expression, b=variable, c=expression ) -> limit(a, b, c) integrate : integrate ( e1=expression, a=term ) -> integrate(e1, a) solve : solve ( e1=expression, a=term ) -> solve(e1, a) term : ( expression ) VARIABLE NUMBER unary: ( + - )* term mult : unary ( ( * / ) unary)* add : mult ( ( + - ) mult)* expression : add ( ( = <> < > ) add)* VARIABLE: a.. z ( a.. z )* NUMBER:

4 Figure 5. Syntax-directed translation.

5 Figure 6. The main window of CAS-Translator. The structure -> limit(a, b, c) shows that the sentence, which was recognized with the rule limit, will be translated into intermediate language with the sentence limit with necessary arguments. The text will be generated from intermediate language to another CAS language (for example, Maple language) with rewriting rule: limit(a, b, c) ::= "limit(<a>, <b>=<c>) <\n>" Fig. 5 shows how one command (integrate) in one CAS language (Maxima) is translated to another CAS language (Maple) through syntax-directed translation. The middle column contains different stages of the translator the other columns contain different inputs and outputs. Our trial application CAS-Translator was written in Java programming language. The main window of the program is shown on Fig. 6. The window is divided into three parts: the left part is for input CAS language, the right part is for output CAS language and the middle section includes several buttons. The user has to select an input language after which the user can enter commands into the box or open a file with commands in the input language. The user has to select an output language as well. After that the user can press the button Translate and the program will translate the commands from input to output language. The commands from the output box can be saved to a file. VI. FUTURE WORKS The first thing that can and should be done is addition of further CAS languages. At the moment our prototype works only with three CAS (Maxima, Maple and WIRIS), but there are many other and even more popular systems (for example, Mathematica, Derive, MuPAD, and so on). In addition, we focused only on commands, but worksheets usually contain a large amount of other information too. The future application should work with different formats of worksheets, open them and translate other information correctly to a needed CAS. Besides translation between different CAS the application could do even more in the future. The current CAS-Translator can take input in the form of command or worksheet. The future application could accept voice and handwritten commands. Voice commands would enable input without a keyboard. It could be useful for people with disabilities. Some existing CAS (for example, Mathematica) already enable entering commands by hand, which is certainly a quicker and more convenient way for doing that. It would also be wonderful if the application would not only show the result (translated command or worksheet) in its own window, but also run the CAS itself and display the result in there. This would make it possible for students to see the result immediately on an interactive board, for example. And teachers could use the program from any position in the classroom (using voice commands). Fig. 7 shows several potential future usages of the application. VII. CONCLUSION The aim of this paper was to investigate, if using syntaxdirected translation could be a viable way for translating worksheets of different computer algebra systems. We can conclude that, at least in a restricted area, syntax-directed translation is possible. Theoretically, it could also succeed in much wider areas, perhaps universally, even though this may be too complicated in practice. The main obstacle is the lack of available grammars of different CAS. Composition of grammars from user manuals is quite inconvenient. However, it is not a major problem if the work is restricted to a particular area. It should be noted that the technique introduced in the paper is not only useful for translation of CAS worksheets but also for controlling a CAS session by voice or by handwriting. These features could be applicable in teaching and learning of (school) mathematics. ACKNOWLEDGMENT The study was supported by the Estonian Target Financing Grant No. SF s06.

6 Figure 7. Possible usages of the application. REFERENCES [1] Maple, Math Software for Engineers, Educators & Students, maplesoft.com/. [2] Maxima, a Computer Algebra System, [3] WIRIS, The Global Solution for Maths Education, [4] M. J. Wester, A critique of the mathematical abilities of ca systems, in Computer Algebra Systems. A Practical Guide. M. J. Wester, Ed. John Wiley & Sons, 1999, pp [5] E. Tonisson, Branch completeness in school mathematics and in computer algebra systems, The Electronic Journal on Mathematics and Technology, vol 1(3), 2007, pp [6] E. Tonisson, and N. Velikanova, Answers offered by computer algebra systems to equations from school textbooks, Teaching Mathematics and Computer Science, vol 6(1), 2008, pp [7] D. Constales, Prototypes for the automatic translation of computer algebra languages, Design and Implementation of Symbolic[7] Computation Systems. Lecture Notes in Computer Science, vol. 429, 1990, pp [8] Yacc: Yet Another Compiler-Compiler, yacc/index.html. [9] Lex - A Lexical Analyzer Generator, index.html. [10] Mixima: Mathematica to Maxima computer algebra system (CAS) translator and compatibility functions and application to Quantum Information Programs, [11] T. Daly, M. Wester, A. Hulpke, H. Schoenemann, S. Mechveliani, A. Pinkus, and M. Lavaud, The Rosetta Stone for Computer Algebra Systems, rosetta/htmla/roseta.htm. [12] A. Cohen, H. Cuypers, K. Poels, M. Spanbroek, R. Verrijzer, WExEd - WebALT Exercise Editor for Multilingual Mathematical Exercises, Proc. First WebALT Conference and Exhibition, Eindhoven, The Netherlands, 2006, pp [13] A. V. Aho, M. S. Lam, R. Sethi, J. D. Ullman, Compilers: Principles, Techniques, & Tools, 2nd ed., Pearson Education, [14] Extended BNF. ISO/IEC 14977:1996. [15] ANTLR Parser Generator,