I think writing the parser would be a GSOC project in itself. Also, I think I don't have the expertise to write the parser. Though it is possible that I can read up and try to implement, I think I won't be able to do a good job of it.
I would like to take up the take up the task of implementing the gamma sympy site by including the following: 1) Back end for svgFig, so that we can plot figures on GAE. As svgFig is written in python, GAE won't have a problem with it. 2) Sphinx documentation integration to the site. Suppose we call integrate, the site should show links to documentation such as sum, definite integral how-to etc. 3) Integration of python terminal as in sympy Live. This will be hidden by default and can be accessed whenever it is required. 4) Make the site render on both hand held devices and computers using twitter bootstrap. 5) If time permits, I would like to write the backend for ascii plots. This looks like a really fun project and I think it is necessary on the command line/ipython if the computers don't have matplotlib preinstalled. This will allow us to plot without any dependencies. Thanks, Bharath M R On Friday, March 16, 2012 4:28:50 AM UTC+5:30, Joachim Durchholz wrote: > > Am 14.03.2012 14:15, schrieb Sergiu Ivanov: > >>> On the other hand, you can switch the parsing techniques much easier > >>> if you are using parser generators. > >> > >> No, not at all. > >> All parser generators have a different input syntax, different > mechanisms to > >> attach semantic actions, etc. > >> That's a decision that cannot be reversed easily. > > > > I see. I thought the differences in syntax were not that influential. > > Well, it's not just syntax. The way you express semantic actions can > have a deep impact. > It's alike the similarities and differences between C and Pascal: both > are statically-types, imperative language with little thought for > modularity. Still, you wouldn't want to rewrite programs from one > language to the other, not even as small ones as 500 lines. > > >>> and http://pypi.python.org/pypi/modgrammar > >> > >> - Cannot handle left recursion (BLOCKER) > > > > Hm, thanks for pointing out. I tried to check that yesterday and I > > still cannot find the information in their docs (at least direct > > searching for "recursion" doesn't work for me). > > http://packages.python.org/modgrammar/tutorial.html#left-recursion > > Last paragraph of the section. > > The point here is that while a left-recursive and a right-recursive > grammar are equivalent in the set of inputs that they accept, they > generate different parse trees. > > >>>> Spell checking, again, is something that is easily done on the parse > tree > >>>> after it has been created. > >>> > >>> > >>> I'm not sure I agree. Consider the (supposedly valid) sentences > >>> "integrate sin(x) by x" and "limit sin(x) when x goes to zero". I > >>> don't think I'd recommend parsing these two sentences with one > >>> (general) rule, which means that the words "integrate" and "limit" > >>> actually determine which of the rules to use. If spell checking > >>> doesn't happen before lexing, the necessary difference between > >>> "integrate" and "limit" may not be detected. > >> > >> > >> Where does spell checking factor in here? > > > > I wanted to say that if "integrate" and "limit" belong to different > > classes of symbols, then, should the lexer encounter "intgrate", it > > wouldn't be able to correctly classify it as "integrate". > > Hmmm... that usually doesn't end well. You never know whether a > particular misspelling was intentional or not. > > E.g. is "limits" a misspelled keyword, or a free variable because he's > doing some first-order logic on interval arithmetic (where he might be > manipulating sets of limits, i.e. upper/lower bounds). > > The standard advice to programming language designers is that this is > One Of Those Well-Intentioned Bad Ideas From The 50ies. > Other ideas like what were "make a programming language look like > English" (that gave us Cobol), or "put all good ideas into one language > to give use the One True Language That Has It All" (that gave us PL/I). > > That doesn't mean that this kind of advice is always valid, but you need > to know what you're doing and why those approaches failed, to avoid > falling to the same traps that have been known for over half a century now. > > >>>>> The preprocessor could also drop > >>>>> incomprehensible (and thus supposedly meaningless) words, like in > >>>>> "find the integral of x^2". > >>>> > >>>> Experience with this kind of approach was that it tends to reduce > >>>> predictability. In this case, the user might consider a word > meaningless > >>>> but > >>>> the program has some obscure definition for it and suddenly spits out > >>>> error > >>>> messages that refer to stuff that the user doesn't know about > >>> > >>> I don't think this is a problem because the user is not supposed to > >>> purposefully input meaningless words in normal scenarios. > >> > >> Then I don't understand what purpose the mechanism serves. > > > > I was thinking about the situation when the user intuitively enters > > some text which includes elements of a natural language (like "find" > > and "the" in "find the limit sin(x)/x when x goes to 0"). In this > > case the user thinks that all words are meaningless, but, for the > > application, "find" and "the" bear no meaning. > > Well, it's really hard to write a parser that does this kind of stuff > well enough to be worth it. > I do not know of a single project that successfully implemented such a > thing, but about several that failed abysmally. > > You're trying to get a DWIM thing implemented. > See http://catb.org/jargon/html/D/DWIM.html . > The first rule for this kind of thing is: Don't guess what the problems > are, go out and watch what problems bite the users in reality. Then add > some (cautious) spell checking and other DWIM mechanisms, and > iteratively correct them until they do *far* more good than harm. > It's nothing that can be designed. You need to deal with what people > actually do (and, hence, it is probably too much work for the current > size of the SymPy community). > > We could start that by adding some statistics code to SymPy: which > functions are used, what kinds of errors happen, where do they > originate. Define a mail address to send them to, write the tools to > extract information from the raw data. Think about how to ask the user > about whether collecting usage data is okay for them (some might > disagree, an NSA mathematician working with SymPy on some secret > research would most certainly disagree). > > -- 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/-/AwIFeazcbT8J. 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.
