On Tue, Mar 8, 2011 at 9:39 AM, Aaron S. Meurer <asmeu...@gmail.com> wrote: > > On Mar 7, 2011, at 10:48 PM, Brian Granger wrote: > >> 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+… > > So maybe it makes sense to put Manipulate in a separate project. Remember > that we want SymPy to remain dependency free, but other projects can depend > on SymPy (and other things). > >> >>> >>> 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… >> > > It might make sense to fork the quantum module, or maybe just the entire > physics module, if it becomes too large. Right now it is not, so there is no > problem with it. I don't see any problem with keeping the fork under the > sympy community. If it happens, we could just give it its own project in > GitHub in the SymPy organization (i.e., just a separate repository here: > https://github.com/sympy/).
I think forking the entire physics package would make the most sense as it is very likely that different submodule of sympy.physics would depend on each other. What do you think the best to name and manage forked subprojects would be? It would be great to have sympy.physics still be the same name, but just a separate project. Cheers, Brian > Aaron Meurer > >> 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 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. >>> >>> >> >> >> >> -- >> Brian E. Granger, Ph.D. >> Assistant Professor of Physics >> Cal Poly State University, San Luis Obispo >> bgran...@calpoly.edu >> elliso...@gmail.com >> >> -- >> You received this message because you are subscribed to the Google Groups >> "sympy" group. >> 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 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. > > -- Brian E. Granger, Ph.D. Assistant Professor of Physics Cal Poly State University, San Luis Obispo bgran...@calpoly.edu elliso...@gmail.com -- You received this message because you are subscribed to the Google Groups "sympy" group. 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.
