From: Dave Raggett <dsr@w3.org>

Date: Thu, 18 Apr 96 23:02:19 0500

Message-Id: <199604182252.AA078767945@w3.org>

To: w3c-math-erb@w3.org

Date: Thu, 18 Apr 96 23:02:19 0500

Message-Id: <199604182252.AA078767945@w3.org>

To: w3c-math-erb@w3.org

Neil writes: > It would be useful for those of us who don't have prolog on our > machines if you would include the sample output along with your > sample input. Okay I will include some in the comments. You should be able to download a free Dec10 style prolog for most platforms though. Note that I expect to switch to C or Java for the final version of the reference code. Prolog is a great prototyping tool and makes it practical to write parsers in a few lines of code that are relatively declarative. > I am confused how you deal with parens and functions. > I didn't see any definitions for them parens are treated as operators although { and } override other kinds of parens. I haven't treated < and > as parens though as these seem more appropriate as infix operators. The tokenizer maps "(" to the term left:'(' and "]" to the term right:']' etc. Functions are handled by mapping say sin(x) to sin.(x) or "sin x" to "sin.x" Where the implied "." operator is left associative like "+". I haven't got further than this, e.g. on how to distinguish polynomial expressions from functions. We discussed this recently by phone and I will tryout the rule you suggested. > 'integral' also seems to be missing This is currently handled as a literal rather than as an operator. The next step will be to combine top-down parsing based on templates with bottom-up parsing using operator precedence analysis to avoid inappropriate bindings: "+ integral of" current reduces the "+" first which is wrong. The template would force this to be reduced to the right overriding the normal precedence values. When I thought about treating integral as a prefix operator, I got stuck with how to handle from and to. If these were prefix operators you then end up with: {{{integral {from 0} . {to n}} of {sin.x}} wrt x} This works I guess, but feels wrong to me. I think the use of templates to influence parsing makes more sense, as it breaks out of the limitations of using operator precedence alone. Treating + and - as n-ary rather than binary operators is an interesting idea, but can perhaps be handled via the code that exports the expressions to say Mathematica or Maple. I have included operators for limits, subscripts and superscripts. Its interesting to note that limits are left associative while scripts are right associative based on the interpretation of superscripts as powers, e.g. y = x^y^z is y = {x ^ {y ^ z}} For limits on integrals and presumably sum and prod etc. I have used an infix operator "of" to bind the integral sign to the integrand, e.g. {{{integral from 0} to n} of {sin.(x)}} wrt x I couldn't work out how to make dx and dy etc. bind to the appropriate integral for a double integral. The "wrt" operator sidesteps this problem though. The use of templates to guide parsing should fix this problem. DaveReceived on Thursday, 18 April 1996 18:52:33 UTC

*
This archive was generated by hypermail 2.4.0
: Saturday, 15 April 2023 17:19:56 UTC
*