Ondrej, Great thoughts, comments inline...
> 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. Sounds great. > 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 think this is a good idea, but I think we should handle this like numpy does and have Matrix subclass array. > 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. We definitely need to abstract the plotting libraries out of the core plotting. At some level, the core printing logic in sympy involves things like: * Deciding on the limits and points to plot at. * Evaluating the function at the points. >From there, having renderers (seems more like rendering rather than "printing" - in IPython we are using the notion of "display" to distinguish rich display of data from "printing" which has a very low level connotation) take the data and render it appropriately is a great design. > 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. I don't think that sympy is the place for this. Manipulate logic much more belongs in places like IPython, traits, etc. At some level Manipulate *is* equivalent to traits - we just want an HTML5/JS version of it. We are starting to move forward on this and I think I see how to support this in a very general manner. But this stuff is of interest far beyond just sympy. Part of this is how I think about Python and Sympy. For me: Sympy != Mathematica But IPython+Sympy+Matplotlib+Traits+Numpy+Scipy == Something even better than Mathematica+Matlab+... > > The above are things that I am aware of at least. I think the most important things are related to patterns, rules, replace, and sets/elements. There is also logic like Hold and distinguishing between Mutable (which we don't have) and Immutable types. > > 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. As you know I *completely* share your vision here. I just think the GUI/numerics/plotting/etc should be kept in numpy/scipy/matplotlib/traits/... I *love* the loosely coupled/library approach of sympy and how it plays with the other tools. But the balance is quite subtle. For example, right now, having the quantum stuff in sympy makes a good amount of sense. BUT, given the magnitude of some of the things we are thinking about doing with it, I am not sure it really does make sense in the long run. But, having the quantum stuff as part of the sympy *community* does make sense. This is where I *really* wish we had solid namespace packages. What about a simple version of it using pkgutil: http://docs.python.org/library/pkgutil.html That would allow us to have different sympy packages with their own release schedules, installation scripts, dependencies, etc. Not sure if this makes sense... Cheers, Brian > 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. > > -- Brian E. Granger, Ph.D. Assistant Professor of Physics Cal Poly State University, San Luis Obispo [email protected] [email protected] -- 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.
