On Wednesday, March 14, 2012 2:28:12 AM UTC+5:30, Joachim Durchholz wrote: > > Am 13.03.2012 21:17, schrieb Aaron Meurer: > > So would it help to start a wiki page where we list all the things we > > want to support, in the order of importance? > > Here's a beginning of that list (in order): > > > > - SymPy syntax: This is probably obvious, but correct SymPy/Python > > syntax should always be parsed exactly as it is given. If the > > heuristic parser has ambiguities problems that would prevent this, we > > can just preparse with a call to sympify(), and only use heuristics if > > that fails. > > > > - Mathematica, Maple, Maxima, etc. syntax. Where they conflict, we > > should pick the more popular variant, or if that's nontrivial, we can > > just let it decide as a side-effect of the implementation (i.e., leave > > the behavior undefined in that case). > > > > - LaTeX. The ability to parse LaTeX math into something that can be > > computed would be very useful. WolframAlpha has support for this. > > It's almost guaranteed that combining syntaxes from different sources > gives an ambiguous grammar. The only technique that can deal with that > would those in the succession of the Earley parser. > > I see that http://en.wikipedia.org/wiki/Earley_parser lists four > different Python implementations, one of them just 150 lines. > > > - Text based math. What I mean here is, it should support parsing > > things as you would type them in plain text without trying to follow > > any kind of set grammar. Stuff like 3x^2 + 2, d/dx x^2. > > That's really hard to do well. Most of the time, the users's guess of > the parser's guess will be quite different than the actuall guess of the > parser. > > > - Special symbols: Support stuff like √x or ∫x^2 dx. Allow, to some > > degree, pasting in stuff from the SymPy pretty printer (in particular, > > things that are not printed on more than one line, like 3⋅x₃). > > That's simple. Just plop in the appropriate grammar rules. Make √ a > prefix operator, ∫...dx a "circumfix" one. > ₃ would probably have to be lexed as <sub>3<endsub>, where <sub> and > <endsub> are synthetic lexer symbols. > > > - Text based functions: Stuff like "integrate x^2 dx", "limit x^2 > > with respect to x as x approaches infinity". > > > > - Natural language processing: There is a vagary between this and the > > last bullet point. What I mean here is that it tries to guess what is > > meant from a plain text description without using a set grammar. This > > could even support stuff like "the integral of x squared with respect > > to x". > > The same caveat as with "text-based math" apply. > > > Shall I start a wiki page? I know there have been other things > > discussed here, like unary minus and bra-ket, that can be problems > > that are important to consider. > > I see two things that need a decision: > > 1) Whether supporting such a wide array of syntaxes is such an important > goal. > If yes, Earley parsing it is. > If no, it would be defining our own syntax, possibly similar to existing > symbolic math languages, but still a separate syntax. >
I am a complete noob here. But if we are trying to implement wide array of syntaxes, can't we write separate parsers for each of them and combine them with a try exception statements Say we have a latex input . Then try: sympify(input) except InterpretationError: try: mathematica(input) except InterpretationError: try: latex(input) except InterpretationError: throw Exception("Not interpreted") Something like the above. This might help us to divide the task of writing a parser and also the need make the parser universal and hence can reduce the complexity of the parser. > From user's perspective, the consequence of an Earley parser would be > that an additional error mode: the input text might have multiple valid > parses. > (How to best present that to the user might be one or more GSoC projects.) > > The consequence of a non-Earley parser, regardless of technology, would > be that we'd have to drastically cut down on the allowed syntax. > Essentially, we'd have to resolve all potential syntactic ambiguities > when writing the grammar. > > I think this decision does not benefit from a Wiki. > > 2) Which grammar rules to support. > > This is a bit tedious: look up what the various syntaxes have, write it > down. > > A wiki page would be useful for that. > > -- You received this message because you are subscribed to the Google Groups "sympy" group. To view this discussion on the web visit https://groups.google.com/d/msg/sympy/-/8FRhiVrTu3kJ. To post to this group, send email to sympy@googlegroups.com. To unsubscribe from this group, send email to sympy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sympy?hl=en.