From Maple to MuPad François Thomasset -- INRIA Rocquencourt -- October 2001 Version 2.0 Francois.Thomasset @ inria.fr $Revision: 1.1.1.1 $ $Date: 2002/03/08 08:31:57 $ This tool aims at helping you to convert your programs written in Maple into programs in MuPad, with hopefully the same semantics. It performs mainly syntaxic conversions, and does not perform any semantic analysis, except some local checks. Using the tool does not exclude that you should perform manual transformations, either on the input Maple code, or on the generated MuPad code. It runs under Unix (SunOs, DEC-ALPHA,...) or Linux (2.1, 2.2... Not 2.0). PLEASE READ CAREFULLY THE SECTION ON RESTRICTIONS (SEC.3 BELOW) IN CASE THE TOOL DOESN'T TRANSLATE YOUR CODE AS YOU EXPECT! SEE ALSO FILE WHAT_IT_DOES WHICH GIVES A SUMMARY OF TRANSFORMATIONS CURRENTLY PROVIDED. Please send me a mail if you use this tool. Note that we use Maple 7 and MuPAD 2.0. This tool has been developed in cooperation with Paul Feautrier (Université de Versailles/StQuentin en Yvelines, Laboratoire PRiSM, and INRIA Rocquencourt). 1/ Installation. ============= 1.1/ First untar the tar file: zcat maple_2_mupad.tar.gz | tar xvf - 1.2/ In the directory ./Maple_2_MuPad/bin/, you will find several kinds of executables: . bin/maple_2_mupad: OCaml bytecode: ocamlrun must be available to run this. . bin/Linux/maple_2_mupad: standalone executable for Linux. . bin/OSF1/maple_2_mupad: standalone executable for DEC Alpha. . bin/SunOS/maple_2_mupad: standalone executable for SunOS (Solaris). 1.3/ If this does not work, you will have to build your own executable. For this purpose, you need to have Objective Caml installed on your machine; here is the web site where you can get information about OCaml and how to obtain it: http://pauillac.inria.fr/ocaml/ Once you have installed OCaml, check that ocamlc, ocamllex and ocamlyacc are on your search path. Then go to directory Maple_2_MuPad and type make; hopefully this will build a new executable bytecode ./bin/maple_2_mupad. On the other hand "make native" should build a standalone executable in directory ./bin/$SYSTEM, where $SYSTEM is given by `uname -s` (e.g. SunOS or Linux). This directory is created if it does not exist. 2/ How to use it. ============== Check that the appropriate executable maple_2_mupad is in your search path. The simplest way is to use the standalone executable corresponding to your own machine. If you choose to use the bytecode, check that ocamlrun is also in your search path. See the Ocaml web site for information on Ocaml: http://pauillac.inria.fr/ocaml/ If your file is named myfile.mpl, type: maple_2_mupad myfile.mpl This should create a file myfile.mupad which MuPad is able to read. If your Maple file is not suffixed by "mpl", then suffix "mupad" is added to the file name to create the name of the result: maple_2_mupad chose So the result of the translation will be in file chose.mupad. As an option you can indicate the evaluation level that you want inside your file: maple_2_mupad -l 100 chose This command will cause the insertion of an assignation of LEVEL at the beginning of the translated file to the value you give after "-l". The default value is a level of 100. If you specify "-nl", then no insertion of a LEVEL assignation is inserted: maple_2_mupad -nl truc Note that I don't check the number of "-l" or "-nl" options which you give on the command line: the last one on the line is effective. You can give several filenames on the command line, which the tool expects to contain Maple programs to be translated. Finally, several ancillary options: . option "-V" prints the current version number. . option "-v" makes the tool verbose: prints the version number, and signals each file that is being translated. Furthermore, the tool produces a message whenever it encounters a call to a function that was not in its table; this may be either a user defined function, or a system function that I omitted to translate. . option "-h" is a small help giving the options. For some constructions I had to use some auxilliary functions whose mupad code is given in file ./auxi/auxi.mupad in this distribution. See file WHAT_IT_DOES for the constructions that require these functions. In case you do need them, you will have to read them in your MuPad session: >> read ("auxi/auxi.mupad"); 3/ Current restrictions. ===================== I have done my best to do the translation; however if any problem occurs, please email me: Francois.Thomasset@inria.fr I will try to tell you if this is a problem that we can solve, and if this is a matter of minutes, hours, days, weeks, years... But please check beforehand the restrictions list below. Note also that you can use the verbose option "-v" (see above) to check if I have forgotten to translate one of the kernel functions you call. 3.1/ Comments. There is one restriction that is not going to be suppressed soon: my grammar insists that a comment is between two statements (so after a colon or semi-colon). Our problem is that we want to keep the comments in the intermediate representation (to reproduce them in the MuPad code), and therefore we decided to attach them as attributes of the statements. It's feasible to attach them to other non terminals (e.g. expressions), but this requires more work than we are ready to give at the moment. 3.2/ Tests on types. Some tests on types may go wrong: for instance, I have translated the type constant of Maple as a disjunction of equality to DOM_INT, DOM_RAT or DOM_FLOAT. This may be wrong in some rare cases. Comparison with type 'linear' is checked by a call to my own function is_linear, in file auxi/auxi.mupad. 3.3/ Side effects. Translation may go wrong if your Maple code does side effects. E.g. S1 := table ({x = 1}): S2 := table({x=2}): text_ := [S1,S2]; S := text_[1];S[y] :=3:text_[1][y]; In Maple, the side effect is visible: text_[1][y] displays 3. A dataflow analysis would be required to detect that a name indicates a part of a structure and that the user performs a side effect. And I don't plan to implement such an analysis. As a matter of fact we have rewritten our own Maple codes to eliminate manually such (unclean!) side effects. 3.4/ Since assign is a reserved in MuPad, I have translated identifiers of this name to "__assign"; same for "is", "expr", "TRUE", "FALSE"; check if this creates a conflict for you. 3.5/ The test for comparing with type "polynom" is going to fail: even if I said "DOM_POLY" for "polynom", it would never succeed, as far as I understand polynomials under Maple and MuPad; in Maple, an expression has type "polynom": > type(x+y,polynom); true But in MuPad, the type DOM_POLY is obtained for the result of applying poly to an expression: >> type(poly(x+y,[x,y])); DOM_POLY >> testtype(poly(x+y,[x,y]),DOM_POLY); TRUE >> testtype(x+y,DOM_POLY); FALSE I have no way to guess that a call to function poly might be needed. At best I could emit a warning when I see a such a call to "type" with argument "polynom". 3.6/ Generation of new symbols. In MuPad, this can be done with function genident, which takes a string as argument: >> genident("b");type(genident("b")); b2 DOM_IDENT I don't know any such function in Maple; we obtain the same effect by using concatenation, but I wonder how I may recognize that a concatenation is meant as a construction of a new identifier, since it can also be used to catenate strings. For this purpose, the tool should be able to check statically the type of all variables, i.e. perform some (interprocedural) data flow analysis. And this is beyond what I want to achieve in the next future. To get around this problem, I assume that your new symbol construction is embedded in a function named newvar; I replace this by a call to genident with a string, which is just the original parameter if I find this is a string, otherwise the name of the parameter between double quotes: newvar(i) genident("i") newvar("i") genident("i") Now this fails if you have previously put into an identifier the basis which you want for your new symbols: b := "X"; newvar(b); This scheme will produce identifiers whose names are prefixed by "b", and not by "X". Of course the name newvar happened to the name we used in our own codes; it could become a parameter. 3.7/ Operations on relations. In Maple, multiplying (or more generally applying an operation) to a relation propagates the operation inside the operation: > 3 * (0<=x); whattype(3*(0<=x)); 0 <= 3 x <= In MuPad, the multiplication stays outside: >> 3 * (0<=x); type(3*(0<=x)); 3 (0 <= x) "_mult" I have no way to correct this without doing type analysis. 3.8/ Call by name (thanks to Dan Stanger for this example). In Maple you can assign a parameter: f(x):=x::2; f(y); y; prints the value 2. I see no way to express this in MuPad. 4/ Error messages. =============== Since I might have forgotten (purposely or not) some aspects of Maple, you might get several kinds of errors: 4.1/ Unexpected character in line XX : C This is a lexical error: XX is the line number in your file where a character is encountered which my lexical specification does'nt know (e.g. an accentuated letter), and C is the contentiuos character. 4.2/ Parse error in line XX Position : YY ZZ Syntax error: a syntaxical construction is found which does not match my grammar. As before, XX is the line number, and YY, ZZ are character positions pointing to the last matching string. You can use emacs and command goto-char to find these positions in your file. 4.3/ I make a number of checks during the analysis or during the production of MuPad constructs. I may have to emit messages which diagnose some problematic situation. These messages start with "ERROR" or "WARNING", according to my estimation of how serious the problem is. An "ERROR" stops the translation at once. Again please email me if you don't understand what's happening. 5/ To be improved. =============== 5.1/ Indentation might be improved; in fact the tool compares the current column with a fixed position (presently 90); when it is about to write beyond this position, it emits a newline and indents by the same amount as the current line was indented. It would look nicer if I chosed to compare the maximum with the position expected after emitting the next expression. 5.2/ Since a number of choices were made in this translation, which are convenient for us but not for all users, we might imagine opening a dialog box under a number of contexts, and asking the user about the translation he actually wants. 5.3/ Recognize more calls to function convert. 5.4/ Improve the precision of warnings. This requires that I insert positions in the source code into all constructions of the intermediate representation. This requires some time. 5.5/ Long term project: build a data flow analysis to ovewrcome the above mentionned limitations. I am not sure this is worthwhile: the tool has already provided the service we expected from it. ============================================================================== Copyright © 2001-2002 François Thomasset, all rights reserved. Copying is covered by the GNU General Public License (GPL). This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version. This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details. ==============================================================================