> What we have now is very limited, and the way that it's done will not > work. We have two kinds of parsers in SymPy right now. There's > sympify(), which parses an expression in Python grammar and converts > unknown variables into Symbols, literals into corresponding SymPy > types (like 1 to Integer(1)) and operations into corresponding SymPy > operations (like 1/2 to Rational(1, 2)). This only works with > expressions in Python notation (we allow ^ for exponentiation, but > that only works by replacing all instances of ^ with ** before doing > any parsing). > > Then we have some very limited parsers for things like mathematica and > maxima. These are almost completely useless. Aside from not really > implementing very much, the problem is that they use regular > expressions. But regular expressions do not work for parsing, because > the expressions that we are parsing are in a higher grammar. Namely, > it's impossible to do things like parenthesis matching with regular > expressions. >
> What is really needed is a parser, that goes through an expression, > and builds a syntax tree out of it. What you need to do is build > something that is modular enough that you can easily plug in new rules > to it (like "integrate expr dx" => integrate(expr, x), or "x y" -> > x*y). > This looks interesting. I recently did a course on finite automata and I think I can use the things I learnt. I need to read up on parsing though. Also, I think that we can only support basic implementations of functions by this method. I mean the functions have to have maximum of 2 to 3 arguments. Otherwise it will be highly inefficient to type things after one another with a space. This would mean that the new parser will only be helpful in implementing the web interface and not sympy in general. > By the way, on a slightly related note, here are some other things to > think about doing as far as heuristics go. First, automatic spelling > correction, so if I type "intergate x^2 dx", it gives me automatically > "integrate(x**2, x) == x**3/3", with a message saying "did you mean > "integrate x^2 dx" with "integrate" underlined (like happens when you > do a Google search). Second, automatic correction of mismatched > parentheses, so if I type "sin(x*(x + 1)", it automatically guesses > that I meant "sin(x*(x + 1))" (WolframAlpha does this). Obviously, > these would both be limited functionality, and are not required for > the project, but they would be neat and useful to have. > I think it will be easy to implement the above features if I parse using a syntax tree. > >> > >> > > >> > 2) An incremental search for functions in symPy > >> > Its very important for a person to get to know the particular function > >> > he > >> > wants to use. This will be implemented using ajax calls to the sphinx > >> > documentation database.This will be similar to search in scilab / > >> > mathematica. > >> > >> Additionally, there should be links throughout the interface to the > >> relevant Sphinx documentation for the various functions used (similar > >> to in WolframAlpha). > >> > >> > > >> > 3) A lyx/ Mathematica styled input. > >> > This greedily converts the expressions into latex symbols, so that the > >> > user > >> > knows what he is actually computing. We can also add a set of symbols > >> > for > >> > summation, integrals, differentiation as a bottom bar. The input will > >> > look > >> > like latex input to the user, while we convert the expressions into > >> > required > >> > symPy functions in the backend. > >> > >> How did you plan to implement this? For now, the way that I know to > >> do it is to first compute the whole expression to SymPy, then call > >> latex() on it, and parse the latex with MathJax. That is what happens > >> at SymPy Live. It sounds like you want something that lets you type > >> LaTeX styled math on the fly, which basically amounts to an equation > >> editor. > > > > I was thinking something like http://www.texrendr.com/. > >> > >> > > >> > 4)Matplotlib for plotting > >> > We plot the expressions, if it is plottable just as Wolphram Alpha by > >> > default. > >> > >> The app engine now supports numpy, so this should be doable (I hope). > >> Our matplotlib plotting engine is still in its infant stages (for now, > >> it only lives at https://github.com/sympy/sympy/pull/673), but it > >> should grow. Hopefully we will get another project that will improve > >> it. You could also spend some time of this project working on it, > >> though obviously it would be better if most of the time were spent > >> doing the other things. > > > > > > Looks like I have to go with svgfig on this. The discussion at > > ( > http://old.nabble.com/Pure-python-matplotlib-for-Google-App-Engine-td32721389.html > ) > > says that a lot of c++ code has to be rewritten in python. I can write a > > backend for svgfig. > >> > >> > > >> > 5)Ipython like notebook. > >> > I think it is possible to port the Ipython notebook according to this > >> > > >> > discussion( > https://groups.google.com/forum/?fromgroups#!topic/sage-notebook/re2bUt4vCxA > ). > >> > But the time it takes to port is not very fixed. I want to know > whether > >> > I am > >> > overreaching by including it. > >> > >> Even without the notebook, we should use IPython itself in SymPy Live > >> (http://code.google.com/p/sympy/issues/detail?id=2645), if that's > >> possible. That will give us things like better tab completion and > >> access to IPython magic. My idea is that you should be able to click > >> on a SymPy Gamma calculation and just get a little SymPy Live session, > >> so the two projects are related. > > > > I will figure out whether this is possible. > > You could just do what WolframAlpha does. There, you can't click on > parts of the expression, but there are little links at the bottom for > each of the relevant parts to their docs. > > Aaron Meurer > > >> > >> > > >> > 5) Make the interface look beautiful with twitter bootstrap. > >> > >> +1. I don't know anything about this specific library, but a > >> beautiful, highly functional interface is almost as important as good > >> functionality. > >> > >> Aaron Meurer > > > > -- > > 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/-/pd5QrgBooY8J. > > > > 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. > -- 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/-/hOTuWmm7OTYJ. 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.
