An OpenMath Prototype 1 Introduction

An OpenMath Prototype Andreas Strotmann Stefan Vorkotter Philippe Marti June 25, 1995

1 Introduction We present a prototype implementation of a fairly complex application that uses a lingua franca approach in connecting several independent processes together to form a new system that can solve problems none of the systems connected together can solve on their own. Highlights in our eort are: 1. Lingua franca (an OpenMath prototype) used in all communication between processes, with common syntax and semantics, implemented in a user-extensible fashion 2. o-the-shelf basic communication library (PVM) avoids re-inventing the wheel; provides dynamic host and process control, virtual any-to-any process communication, message buering and mail box handling functionality; assures message order and message completeness 3. both \direct" and \gatewayed" communication implemented 4. avoid central communication bottle-neck through complex communication pattern support 5. real distributed processing 6. very dierent kinds of processes involved in the system 7. coordination of symbolic computation rather than linking symbolic computation system with other kinds of software (e.g. numeric, visualization, or user interface) Other eorts in this area dier from our eort: ASAP provides lingua franca for communicating expressions, but no common \dictionary" or mathematical semantics; de nes its own communication protocol which is stream-, not message-passing based; it requires a central \translator" process (Central Control) { a communication bottle-neck CAS/PI does not use a lingua franca in communication: instead, the central process emulating the \software bus" uses a single internal representation of mathematical objects which is heavily biased by the needs of user interface design; all communication is performed in target system's external language using standard I/O channels; stream-based communication through central communication bottle-neck; emphasis is on user-directed use of several symbolic computation systems through a common GUI. CaminoReal focuses on providing access to CA systems through a formula editor interface integrated in a DTP system; \meaning is in the eyes of the beholder" : syntax, no semantics MP uses common \syntax", little or no semantics; usses its own communication library (though they have realized that that was a mistake); emphasis is on combining numerical applications and symbolic computation systems 1

STURM doesn't use a lingua franca; uses PVM as a basic communication library; uses a similar application problem to test its ideas.

2 Application Description

2.1 The Task

The application that is being used to test the prototype is in the area of real constraint solving. A real constraint system is de ned as a boolean expression with free variables that are implicitly quanti ed over the real numbers. The predicates allowed inthe boolean expression are the equality and comparison predicates (equal, less than, greater than, and their combinations). The left- and right-hand sides of these inequalities may be arbitrary functional expression involving nested real functions and costants. A solution of such a constraint system is de ned to be an instantiation of the free variables of the system with real numbers such that the boolean expression resulting from replacing each occurrence of a free variable by its instantiation is \true". The task that is to be solved is to gain a \certi ed" set of hyper-intervals that cover all solutions of the constraint system (if any exist) without covering too much more than the solution space. One target application area of such a system is that of an engineer trying to nd out tolerances of a mathematically phrased engineering problem.

2.2 The Tools

There are quite a few software systems (i.e. algorithms and their implementations) available today that allow analyzing real constraint systems. Here are a few examples, some of which form part of the application system that has been implemented in this eort: Simplex: The simplex algorithm takes as input a linear constraint system (i.e., the left- and righthand sides of inequations are limited to terms that are linear in the free variables), and it returns a single hyper-interval that is guaranteed to contain all solutions, should they exist. If it returns an empty interval, it guarantees that no solution to the linear real constraint system exists. Interval Propagation: The interval propagation algorithm takes as input a general real constraint system (with evaluable real functions usually taken from a small set including exponential and trigonometric functions) and returns a single hyper-interval containing all solutions, should any exist. Groebner Basis Computation: This class of algorithms can be used to solve exactly a certain class of polynomial systems of equations. Cylindrical Algebraic Decomposition: This class of algorithms provides a decision procedure for arbitrary rst-order logical formulae with quanti cation over the reals, predicates as in real constraint systems, and polynomials as left- and right-hand sides of inequations. Thus, all of the above solve some aspect of the full problem, but none of them solve the full problem. In addition, some of the algorithms mentioned above either do not always converge well (interval propagation) or have super-exponential worst-case (Groebner) or even \normal-case" (CAD) execution time complexity. In fact, each solver has its own input domain, its own output characteristics (semantics), and its own performance characteristics.

2

2.3 Putting it together

It has been observed that there are often cases where through combining the computational characteristics of such solvers it is possible to get results that are much more useful than those produced by the interval propagation algorithm (the only one covering the full input domain). There are a few things that need to be taken into account if a cooperative solver is to be built:  Results found by dierent solvers need to be transmitted to other solvers in order to help solve the whole problem.  Each solver is autonomous. Its code is often proprietary, re-implementation of its algorithms prohibitive.  Some solvers are not \incremental" { they are unable to narrow down a solution by adding new information to it or to remove such information at a later stage.  Each solver is \monolithic": it is not a library of C code but a complete system doing (usually) its own memory management.  No solver may be told the full problem (except perhaps interval propagation), because it cannot handle the full input domain.  Speci c implementations may have their own \quirks".  Results produced by a solver have a semantics de ned by the solver that may need to be translated into the semantics of a cooperative system. A solver may not distinguish between not being able to produce a solution and having established that no solution exists, for example. This means that

 A solver needs to be \incremental", i.e. able to incorporate new information in order to       

narrow down solutions, and able to remove such information again, each solver needs to run as a separate process, control needs to reside in another separate process, solvers need to synchronize regarding branches of the search space they are working on, each solver needs to be told results from other solvers, each solver needs to be told the parts of the constraint system that it can handle, and withheld those that it cannot handle, constraints may need to be coerced into a form accepted by the solver or better suited for the solver, and results may also need to be coerced into a form that accurately describes their meaning within the cooperative system.

Marti and Rueher therefore propose the following main components of the cooperative solver: The Monitor implements the ow-of-control of the cooperative solver. It sends constraints to its solvers, and receives their results. It keeps track of the global state of the computation, synchronizing the branches of the global search space that the dierent solvers are processing. By design, the monitor does not need to \understand" anything of the speci c constraint system domain. Rather, it is modelled as a message-passing based general-purpose mechanism for coordinating constraint solving. 3

The Solvers are the o-the-shelf software systems capable of handling aspects of the real con-

straint system solving problem. The Interface Modules have the task of tting an o-the-shelf solver to the global cooperation model of the Monitor. Depending on the speci c Solver to be tted, this may involve: Input Filtering: extracting the information the Solver can handle from the stream of constraints sent by the monitor. As an example, the Simplex Interface Module withholds a non-linear polynomial equation from its Solver, but passes on any linear constraint. Input Transformation: pre-digesting the input constraints sent by the monitor. As an example, the Simplex Interface Module needs to perform constant folding on linear constraints before handing p them to the Simplex Solver if the linear constraint involves symbolic constants like 2. Input Translation: translating from the standard language used within the cooperative system to the input language of the Solver, unless the Solver understands the standard language. Constraint Store Book-Keeping: If the Solver is not incremental, its Interface Module needs to emulate an incremental solver by requesting the result for the full set of constraints that are relevant to the current branch of the computation. Protocol Gatewaying: The autonomous Solver may not provide a full message passing interface based on the message passing library used in the cooperative solver (i.e., between the Monitor and the Interface Modules). Often, only stdin and stdout are available as interfaces. The Interface Module has to serve as a gateway between these kinds of protocols if necessary. Output Translation: translating from the output language used by the Solver to the language used within the cooperative system. Output Transformation: post-processing the result returned by the solver. As an example, = 1 23 as returned by the Solver may actually \mean" 1 225   1 235 (i.e., the Solver's algorithm only guarantees that the latter holds when it actually returns the former as an answer). A second example that would involve more complex transformations is common in results returned by a Grobner Solver: here, results often need to be phrased in terms of the roots of (univariate) polynomials because no closed-form solution involving n'th roots may exist. In such a case, a single formula may in fact encode the collection of all possible ways of instantiating it with speci c roots of the polynomials involved. In terms of the cooperative solver, this needs to be re-phrased as a disjunction of all these possible instantiations. Output Filtering: making sure that only new and relevant information from the result returned by the Solver is returned to the Monitor. Examples are:  Only narrowed-down interval solutions are relevant; result intervals containing input intervals are not reported.  Only real solutions are relevant; results with non-zero imaginary parts are ltered out. Note: In the current implementation, some of these tasks are still done in the Monitor process, and some are done by driver code in the solver. Of all these tasks involved in the cooperative solver, input and output transformation and ltering require extensive algebraic computation capabilities if they are to be done correctly and without too much loss of information. The speci c implementation language that was chosen for the Interface Modules and for the Monitor did not provide enough of this capability; furthermore, there is quite a bit of code involved in providing guaranteed-precision constant folding, for example. For this reason, an Algebraic Computation Module (ACM) was added to the system, acting as a server accepting algebraic computation requests and returning the answer to the requestor. X

:

:

4

X

:

This module is involved in non-trivial constant-folding required by the Simplex solver, and in guaranteed-precision real-number and full-size integer and rational number arithmetic, especially non-trivial comparisons required for interval output ltering. Figure 1 shows the processes making up the cooperative solver, and the pattern of communication between these processes.

User Interface

Monitor

Algebraic Computation Module

Interface Module

Interface Module

Interface Module

Simplex Solver

Interval Solver

Groebner Solver

PVM-Link (OpenMath)

Prolog

MapleV (research version)

Std. I/O Link (Solver User Language)

Prolog III

REDUCE 3.5

Figure 1: Cooperative Solver Processes and Communication Pattern

2.4 Debugging the Cooperative Solver

There is an advantage to linking the components of such a complex application through a messagepassing system rather than through their standard I/O channels which is easily overlooked but which proved vital during the writing of this particular software: the ability to use the normal I/O primitives and even the built-in interactive debugging tools of the component systems for tracing and interactive debugging, without disrupting the information ow that makes up the cooperative solver. In the particular case of the cooperative solver implemented so far, xterm windows were opened for the Monitor, the User Interface, the Interface Modules, the Groebner Solver, and the Algebraic Computation Module. Debugging the remaining solvers and their links to their respective Interface Modules proved much harder and much more time-consuming. 5

In addition, the XPVM message-passing analysis tool proved very useful in analysing errors in the ow-of-control implemented for the cooperative solver. Examples of this use are easily seen below in the discussion of an example session.

3 Example Session 3.1 Startup Phase

Figure 2: Startup Phase Figure 2 shows the time-line diagram of the start-up phase of the application as produced by XPVM. 1. The monitor process is started from the PVM console. 2. After loading its con guration les, the monitor process starts three slave processes: simplex-slave, interval-slave, and maple-slave, waiting for their ready messages to make sure that they are ready to process messages before sending any. 3. The \slave" processes now start their respective \solver" processes and the user interface process:  The simplex and interval slaves start child processes that are controlled through their respective stdin and stdout channels. Once these child processes (the solvers proper) have successfully loaded their respective con guration les, the slaves send a \ready" message to their parent process, the monitor . 6

 The maple-slave starts a child process (pvm maple) through PVM, waiting for the

4. 5. 6. 7.

solver's \ready" message before sending it a command to load a con guration le. Once the solver has returned a message signalling that it has successfully loaded the con guration le, the maple-slave sends a \ready" message to its parent process, the monitor .  The user-slave (user interface process) reads its con guration les and sends a \ready" message to the monitor process. The slave processes then wait for the monitor to send the task ID of the ACM process. Once the monitor has received \ready" messages from all three slaves it starts the ACM server process (omserver). The ACM process sends a \ready" message to its parent process, the monitor . The monitor process sends the task ID of the ACM server to its slaves. The monitor process waits for a user request.

3.2 Computation Phase

Figure 3 shows the time-line diagram of the distributed processing involved in solving the simple constraint system  3 6 2 2 +6=0 0 X

X

X

;X >

From left to right, the events shown in the diagram are: 1. The user-slave process sends the user request to the monitor : (&and. (= (+ (- (- (pow X 3) (* 6 (pow X 2))) (* 2 X)) 12) 0) (>. X 0))

2. The monitor distributes this request to its slaves:1 (a) It sends the linear part of this request ( 0) to the simplex-slave: X >

(>. X 0)

(b) It sends the full request to the interval-slave. (c) It sends the polynomial equation part of this request ( Grobner solver (maple-slave):

X

3

6

X

2

2 + 6 = 0) to the X

(= (+ (- (- (pow X 3) (* 6 (pow X 2))) (* 2 X)) 12) 0)

3. The maple-slave passes on the polynomial equation to its solver process (pvm maple). 4. The simplex-slave returns an answer to the monitor : (success)

indicating that it found no inconsistency and no additional information. 5. The pvm maple solver returns the full solution of the polynomialequation to the maple-slave: (&or. (= X 6) (= X (pow 2 (/ 1 2))) (= X (- (pow 2 (/ 1 2)))))

i.e.,

X

p

= 6_ = 2_ = X

X

p

2

1 In a later version, the full request will be broadcast to the slaves who will pass on to the solvers the messages listed here.

7

Figure 3: Computation Phase Time Line

8

6. The maple-slave passes on this solution to the monitor . 7. The monitor tells the other slaves (simplex and interval) to mark a choice point.

I think this is wrong. We're still waiting for an answer from interval regarding the current branch of computation, which we will eventually forward to simplex! At that point, backtracking to the current choice point will also discard (at least) the result that interval will send, even though it is \global" information. 8. The monitor sends the rst potential solution (X = 6) to the simplex and interval slaves: (= X 6)

9. The simplex slave returns a success message to the monitor: it has marked a choice point. 10. The simplex slave returns a second success message to the monitor: = 6 is consistent with 0. 11. The interval slave returns its answer to the monitor process: X

X >

(&ge. X 5.99816793420748)

i.e., p  5 99816793420748. Note that this answer is WRONG! It excludes the solution = 2 12. The monitor forwards this information to the simplex slave. The Groebner solver does not receive it as it cannot handle inequations and inexact numbers. X

:

X

Didn't the simplex slave already mark a choice point before receiving this additional info?? I think something's wrong here.

13. The interval solver acknowledges the request for marking a choice point by returning a success message to the monitor. 14. The simplex solver returns a success message to the monitor, indicating that  5 99816793420748 is consistent with its internal state. 15. The interval slave tells the monitor that = 6 is its solution to the subproblem ( 3 6 2 2 + 6 = 0) ^ 0^ = 6 16. The monitor forwards this solution to the simplex slave. 17. The simplex slave agrees that this is a solution, and tells the monitor so. 18. The monitor decides that there are no more messages pending for this branch of the (successful) computation. It therefore asks the simplex slave to give its internal state which in the current implementation de nes the \solution" of the complete system: X

X

X

X

X >

:

X

X

(results)

19. The simplex slave returns (= X 6)

20. This message is forwarded to the user interface (user-slave) which prints it on the screen. Figure 4 shows the subsequent \conversation" in more detail. 1. The monitor tells its slaves to backtrack to the previously marked choice point in order to explore alternative branches: 9

Figure 4: Computation Phase Time Line (Detail)

10

(restore)

why doesn't it tell the maple slave to backtrack??

2. The monitor tells its slave to mark a choice point (as the previous mark has been cancelled by the previous message). p 3. The next branch is characterized by the constraint = 2. Formally, this involves an exponentiation or a square root function, neither of which are within the scope of the simplex solver to deal with. Nevertheless, simple constant folding can transform this exact equation into an inexact equation that holds the maximum amount of information the simplex solver can deal with here. Since the system that is used for programming the monitor and the interface modules doesn't provide the code for general reliable precision calculations of real functions and function terms, the monitor (in a later version of the system, the simplex interface module) requests the ACM module (omserver) to convert the right-hand side of this equation into something the simplex solver can handle: X

(fold (pow 2 (/ 1 2)) 16)

The intended meaning of this message is: do full precision constant folding on the expression (pow 2 (/ 1 2)) to sixteen signi cant digits. 4. The interval and simplex slaves report sucessful completion of the backtracking and choice point marking tasks. 5. The ACM server returns its answer to the constant folding request: 1414213562373095e-15

6. The monitor sends the normalized constraint to the simplex slave: (= X 1414213562373095e-15)

7. The monitor sends the unchanged constraint to the interval slave: (= X (pow 2 (/ 1 2)))

8. The interval slave reports an inconsistency with its own internal state (caused by the miscalculation in the previous step): (fail)

9. The simplex slave reports consistency with its internal state to the monitor, which discards the message as all communication regarding this branch of the computation is now super uous. 10. The Groebner and simplex slaves are noti ed of the backtrack required because of interval's detection of an inconsistency. 11. The simplex and interval slaves are asked to mark a choice point. 12. The Groebner slave forwards this request to the Maple server. 13. The Maple server reports success to its interface. 14. The interval slave reports successful marking of a new choice point. 11

15. The interface (maple-slave) forwards the success message to the monitor. 16. The monitor requests the ACM module to pre-process the next constraint for the simplex solver: (fold (- (pow 2 (/ 1 2))) 16)

17. The ACM server returns its answer to the constant folding request: (- 1414213562373095e-15)

18. The monitor sends the normalized constraint to the simplex slave: (= X (- 1414213562373095e-15))

19. The monitor sends the unchanged constraint to the interval slave: (= X (- (pow 2 (/ 1 2))))

20. The interval slave reports an inconsistency with its own internal state. 21. The simplex slave reports inconsistency with its internal state to the monitor, which discards the message as all communication regarding this branch of the computation concerns is now super uous. 22. The Groebner slave is noti ed of the backtrack required because of interval's detection of an inconsistency. 23. The Groebner slave forwards this request to the Maple server. 24. The Maple server reports success to its interface. 25. The monitor decides that it has processed all relevant information, and that it has found at least one solution during the computation. Consequently, it sends a success message to the user interface, which prints it and asks for new user input. Why doesn't it process Maple's answer to the backtrack request rst?

4 Implementation Details

4.1 Data Representation

The following additions to OpenMath were required by our application:

general purpose extensions  (LOAD le)  constant i (imaginary unit)  integers of arbitrary lengths  oating point representation used for arbitrary precision oats (number of digits signi es precision of oat)

special purpose extensions  (fold expression)  (approximate expression precision)  (compare real-expr1 real-expr2) returning 1, 0, or 1  application protocol (see section 4.3 below): fail, success, result, spawned, tell, clear

, ...

12

OpenMath's structure sharing support was not implemented (except in MapleV where it was disabled for our prototype). Implementation of the data import and export operations:  requirements { (applications programmer-) extensibility  techniques (fast prototype) { import single OpenMath string into heap of symbolic computation system { parse OpenMath string into operator tree of SCS (with OpenMath operators)  symbol re-naming to force OpenMath interpretation, if necessary  in Prolog: using pre-compiled lexical analyzer Note: this approach is feasible so far because  OpenMath prototype de nes the semantics of its list structure in such a way that it corresponds to that of operator trees de ned in Prolog, PrologIII, LISP, or MapleV (the systems used)  no mathematical type information is being used yet. { translate OpenMath operator tree to system or user operator tree doing semantic translation or normalization where necessary  example: n-ary to binary +,*; binary to n-ary and,or - translations are rule-based, thus user-extensible (some exceptions to this rule are necessary and complicate handling this translation in some systems)  only known symbols are translated to their system equivalents. this makes it possible to customize the language available to a user of a system, enabling the writing of a public-access demo system for computer algebra.  Prolog-speci c problem: re-interpretation of variables requires application-programmerprovided symbol table for translation as no name mapping to variables is available (and can be available) { perform operation associated with operator tree (may be implicit in translation phase in case of a CA system)  operation may be application-programmer-de ned, thus corresponding translation rule may need to be activated  operation may need to coerce result to an OpenMath-de ned form { translate from system or user representation to OpenMath operator tree within system heap for export  semantic translation  rule-based, thus user-extensible  Prolog: create name-to-variable mapping during translation { generate single OpenMath string from OpenMath operator tree within system heap for export  techniques (possible future optimizations) { break string into lines for smaller string buer (import and export) { parse or print OpenMath string using C (C++) library; import data structure while parsing (MapleV prototype: already implemented) Note: this is not necessarily an optimization, e.g. if highly optimized parse code is easily written, but data structure import requires per-data-element foreign-function call. Note: semantic translations are not feasible in general using such a library. { short-cut translations for eciency-critical objects (import and export) code samples: (to be done) 13

4.2 Protocol PVM:

 functionality used: { string transfer only; OpenMath strings only { message tags (in a simple manner) { simple message passing and mailbox management  non-blocking send  non-blocking mailbox lookup  blocking receive

 dynamic process creation  info functions (buer id, message length, task id (own, parent))  debugging tools used { XPVM message visualization { Xterm windows for interactive debugging of sub-processes (standard UNIX debug-

gers are useless)  message passing properties of PVM library used { in-order arrival of messages on single inter-process link { intact arrival of message (unchanged, guaranteed arrival) { mailbox holds messages until needed { message selection based on sender and message tag { little waste of CPU cycles during waits { small overhead for message passing library implementation  embedded as 'foreign function' C calls in Prolog, MapleV, REDUCE { PVM3 subset only { data import and export: integers, oats, strings only gateway:  fork/join  named pipes (ASCII stream) { ush messages once written, both on interface and on solver (some Prolog systems are unable to do that!) { unexpected error messages are a problem { pipe may hang  syntax analysis tools, con guration le (Prolog)  debugging of message streams { explicit writing to trace le { need to preserve ushing of pipe at both ends complicates debugging Protocol:  all messages use OpenMath prototype language (single ASCII string)  spawning a process { spawning process  spawn child process  wait for spawned process to return a message of pre-de ned tag to avoid sending subsequent messages to non-existent process  (perhaps) inform other processes of newly spawned process using another speci c message tag  send initialization message  wait for successful initialization 14

{ spawned process  initialize  return 'ready' message to spawning process  (perhaps) wait for address(es) of auxiliary process(es)  enter server mode with state
receive message (any tag, any sender) ( rst message will be initialization message)


process message (OpenMath string determines operation)
return result (coded as an OpenMath string) to sender with same tag as

received message The server mode with state proved to be a surprisingly versatile protocol in this context. Global control variables in the server were able to keep the relevant context of subsequent messages, including the logical state of the \virtual machine" they implemented. Message interpretation determined the state change required of the server. This is reminicent of a Turing Machine concept, arguing for its generality, and for the lack of need for a more complex arrangement. In particular, symbolic processing system vendors can provide a single server process (with a single hard-wired receive-eval-send loop) and rest assured that this is sucient for any message-passing application provided that the user may de ne her own commands to be communicated to the server through OpenMath. There are two kinds of clients within our system. The rst uses a simple remote procedure call protocol (send a request and wait for the answer), and the second uses message passing for concurrent processing, needing more intelligent queuing, selection, and processing capabilities for handling answer messages returned by the server(s). Both protocols may be used within the same process, though not between the same two processes. Message selection from the mailbox based on sender and expected message tag makes it possible to avoid interference between these two protocols within a single process.2

4.3 APIs

As noted earlier, we have implemented several dierent symbolic processing servers within the system. The interface and solver servers all implement a fairly small set of operations: init: initialize constraint store tell: adding a constraint to their internal constraint store, choice: marking a choice point in their internal constraint store, backtrack: return to the previous choice point results: report current state of constraint store reset: re-initialize constraint store Note that these are application-de ned operations with general mathematical objects as parameters. Note also that some solvers may be unable to implement any one of these operations, in which case its interface server is responsible for processing the operation for its solver. In addition, a general-purpose 'LOAD' command (not yet part of the OpenMath standard) was de ned to implement reading in an initialization le that de ned these operations. The general-purpose Algebraic Computation Module server, on the other hand, implements the following set of operations so far (in addition to those already de ned by OpenMath): 2 Thus, a server in some cases acts as a client of another server. In our particular scenario it is easy to prove that no deadlocks are possible because of this only: the directed graph consisting of the processes as its nodes and arrows from a client to its servers as its directed links is in fact acyclic, as can easily be seen in gure 1. Of course, this does not preclude other potential reasons for deadlocks in the message dependency graph.

15

 conversion from an expression involving oating point number representations to one involv-

ing rational numbers, to the input precision of the oats involved  constant folding of an expression guaranteed to a given oating-point precision  numerical comparison of potentially high-precision oats and/or rationals This list will be extended in future versions of the application. Other operations that have already been identi ed as to-be-done by the ACM server include:  guaranteed-precision roots of univariate polynomials  Horner representation of polynomials  expansion of constraints involving ROOT OF and ONE OF expressions  type projections (see below) All of these are hard to re-implement properly (e.g. with guaranteed functionality that is so typical of CA applications), arguing for their use through remote procedure calls to CA systems that already implement enough functionality to make implementing the speci c extension required a feasible task. Note that few (if any) of these are available as operations in existing computer algebra systems, but are often fairly easy to de ne using them. Note also the necessity for providing highest-level functionality in order to avoid message passing overhead. Note that, using the RPC paradigm and explicit passing of process addresses, it is fairly easy to handle the case of several ACM servers, each oering dierent highest-level functionality. A service like the Central Control of the PoSSo project could also replace the ACM server, possibly providing load-balancing and capability-dependent server selection in the case of multiple servers being capable of handling a request. Sample code: (to be done)

5 Conclusions scenarios \parallel and distributed processing" (complex communication pattern) and \transparently importing external functionality" Reliable transmission of maths objects and commands necessary for reasonable development of parallel or distributed algorithms in computer algebra or its applications. Extensive debugging is necessary here. Note: parallelization or programming of cooperative processing are already very dicult tasks. user-extensible and -de nable computer algebra operations general-purpose \CA server mode" with state is already very useful for implementing a solver. The trick is for the programmer to write user-extension operations that update the state as required. general-purpose CA \maths library" via message passing to a general-purpose CA server (or several of them) is a very useful concept. Possible tasks: simpli cation, type analysis, type conversion/coercion, speci c CA tasks like integration, solve,... \load" command \user" = applications programmer, therefore somewhat readable encoding most useful ASCII strings (as opposed to binary streams) are most easily processed in real-life maths processing systems (LISP (PSL, ...), Prolog, CLP systems, possibly others). educational value: \reasonably competent" programmers do not necessarily know enough about symbolic computation to write reasonable code interfacing to a CA system { their expertise may be in window system programming or number crunching, none of which are good introductions to symbolic mathematics. OpenMath can serve a highly useful purpose as a model software system, provided that model implementations of OpenMath are made public. 16

Dicult but necessary to keep a CA system from \evaluating" every single component of an OpenMath message during import. State should only be changed once, e.g. General rule-based mechanisms for importing and exporting OpenMath expressions are not always feasible due to special handling of certain constructs. The less a system \knows" about maths, the easier an implementation is. In the areas the system doesn't know, the OpenMath operator tree can already serve as a valid system representation. Do not pre-suppose any knowledge about numeric constants (be it integers or oating point numbers) if reliable computing is the goal. String representations of either may be necessary.

6 To be done Hard problem: generic type coercion with minimal loss of information. Input: generic type de nition, mathematical object Output: \projection" of object to the type Example: a real linear constraint for a speci c system is de ned recursively as follows: 1. a conjunction or a disjunction of two real linear constraints is a real linear constraint. 2. a real linear inequation is a real linear constraint. 3. a comparison between to real linear terms is a real linear inequation. 4. legal comparisons are equal, not equal, greater than (or equal), less than (or equal). 5. a real constant is a real linear term. 6. IEEE oats, arbitrary size integers, arbitrary size rationals are real constants. 7. real variables are real linear terms. 8. adding two real linear terms yields a linear term. 9. multiplying an atom and a real linear term yields a linear term. Thus, the system has a somewhat more rigid view of real linear constraints it will accept than is mathematically necessary. In particular, the real constants are de ned very strictly (sqrt(2) is not a real constant by this de nition, though 1.4142 is). Here, real constant folding would provide such a projection of a computationally real linear constraint to one accepted by this particular system, provided that the constants are calculated to the maximum precision understood by the system. A related problem: \factoring out" such a projection, introducing new variables where necessary. Example: = 1 + 2 + 2 7! = 1 + 2 + (where = 2 is non-linear) x

y

y

x

y

z

17

z

y