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. > 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? > 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 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. -- 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.
