On Thu, Feb 17, 2011 at 8:25 AM, Ronan Lamy <[email protected]> wrote: > Le mercredi 16 février 2011 à 22:24 -0800, Ondrej Certik a écrit : >> Hi, >> >> SymPy is quite close to replace Mathematica for most basic things. > > The major thing that's missing is a nice graphical front-end with a > notebook interface, LaTeX rendering, integrated plots, ... > >> Some features are still missing though, so I will try to implement >> those, but I wanted to discuss my plan here too, in case you would >> have some suggestions, comments: >> >> 1) MatrixForm, TableForm >> >> http://reference.wolfram.com/mathematica/ref/TableForm.html >> >> this I plan to put next to Tuple (sympy/core/containers.py). And >> printers for it into printers. > > This is only for printing so I don't see why you want to handle these > wrappers as containers.
That's what I thought first too. The MatrixForm should print something in ascii, something in latex and something else in html. So I thought, that MatrixForm would be a sympy class, and then the StrPrinter would know how to print it to ascii, PrettyPrinter would know how to use ascii art, LatexPrinter would know how to print MatrixForm class in latex, and finally HTMPrinter (if we have any) would print it in html. So this I know how to implement. How would you implement just a printer? If you can show me how to do it, maybe it's a better way. > >> 2) NumPy array() >> >> So that you can use syntax like: >> >> xdata = array([1, 2, 3, 4, 5]) >> ydata = xdata ** 2 >> data2 = array([xdata, 1.5 * ydata]) >> >> which just works in Mathematica (it's in the core language). >> >> If you have numpy installed, then all is fine, but sometimes numpy is >> not available, for example when you only have pure Python and install >> SymPy. An example is google app engine, or when you don't have root >> access to your computer and so on. So I could imagine having the >> array() function in sympy, and it would try to import numpy lazily >> (when you use it), and if it fails, use sympy's pure Python >> implementation. So that users can simply count, that when they do >> >> from sympy import array >> >> it will just work, always. I plan to put it into >> sympy/utilities/numpy.py so far. > > I don't really see the point of having this in sympy. Which actual > problems does it solve? I replied to that in the other email. > >> 3) Plot() >> >> it should be refactored, so that it only holds the information about >> the plot and handles common parameters. Then there would be >> "printers", to print it using pyglet, or ascii art, or matplotlib, or >> return a link using google chart api, and so on. > > +1 > >> 4) Manipulate >> >> the logic and the class will be in sympy, but to be actually usable, >> it will need some frontend (e.g. browser+ javascript), or Qt GUI. The >> GUI part will not be in sympy. > > As I understand it, a Manipulate object is a graphical widget that can > query the 'kernel' and update itself interactively. I don't think much > needs to be done on the sympy side. The syntax should be in sympy side, so that each frontend doesn't implement a different syntax and behavior. > >> >> The above are things that I am aware of at least. >> >> >> The hard part above is that SymPy should stay as a *library*, which >> means that it should have all the logic, but in order to build an end >> product like Mathematica, one needs to plug in more pieces, in >> particular some gui (and there is tons of options here, e.g. Qt, >> mobile phones, web gui, ...), and faster libraries for doing numerics >> (numpy, scipy, ...), some "data package" (with tons of physical data, >> like chemistry tables, astronomical data, cities, ....) and so on. So >> SymPy is just a component of the whole thing, kind of like "standard >> library" to make Python directly usable for mathematics. > > I agree. But I think that the best way of enabling the creation of good > front-ends is to actually start building one, instead of trying to > anticipate potential problems. Yes, I am building one. Another frontend is Sage, yet another is Femhub, and another is Qsnake (http://qsnake.com/). And I want SymPy to have all the logic, so that once you learn SymPy, you can immediately use it everywhere. Each frontend has it's pro and cons, and my anticipation is that there will not be a single frontend to satisfy everybody. Ondrej -- You received this message because you are subscribed to the Google Groups "sympy" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/sympy?hl=en.
