On Thu, Apr 28, 2011 at 6:59 PM, Ronan Lamy <ronan.l...@gmail.com> wrote: > Le jeudi 28 avril 2011 à 17:43 -0700, Mateusz Paprocki a écrit : >> Hi, >> >> On 28 April 2011 17:06, Ondrej Certik <ond...@certik.cz> wrote: >> Hi, >> >> Should TableForm go into SymPy or not? Here is the pull >> request: >> >> https://github.com/sympy/sympy/pull/268 >> >> here is the discussion at length: >> >> https://groups.google.com/d/topic/sympy/RSOo5cZNd2E/discussion >> >> and here are the examples of usage of TableForm: >> >> https://groups.google.com/d/msg/sympy/RSOo5cZNd2E/8bLSGHqcdU4J >> https://groups.google.com/d/msg/sympy/RSOo5cZNd2E/TWmxeR-0A3gJ >> >> I am +1 to have it in SymPy, Ronan is -1. What do other people >> think? >> >> >> I guess the discussion is whether we want SymPy to contain all >> useful >> code regarding symbolic manipulation, just like Mathematica >> has >> (Mathematica has TableForm in by default). My vision is >> clearly yes. >> But I would like to know the opinion of the sympy community. >> > But printing tables isn't symbolic manipulation. The comparison with > Mathematica isn't terribly helpful since it isn't a library but a > full-fledged programming language, and the IDE that goes with it, and > more things besides.
My vision has always been to take numpy, scipy, matplotlib and sympy, put an IDE around it and get something like Mathematica (or better). > >> >> I didn't look into the implementation yet, but anyway +1 for the idea. >> The question you formulated it broader than this and includes OEIS, >> physics, code generators etc. In my opinion all this should be in >> SymPy and moreover, this is how we (at least I, but I'm sure it's not >> only me) developed SymPy from the very beginning, so I don't see why >> we should change this direction now. I still want to continue going in this direction, but Ronan gave -1 to my patch which implements another little thing on the road (the reason being that it doesn't fit into sympy, not that the patch quality is bad --- which it might be, but that's not what we are discussing now), and as such, I want to open the public discussion about this and see what people think. > > I don't understand how you define "all this". Code generation is > perfectly in scope for a symbolic manipulation library and making sympy > usable for physics calculations is basically a core design goal (though > sympy.physics should ideally be split off into a separate project having > sympy as its major dependency). On the other hand, printing a table and > calling up a bookmark seem rather peripheral to the goal of building a > library for symbolic mathematics. TableForm is extremely useful, people who use Mathematica use it. So it needs to go somewhere. It might go into SciPy, but given all the printing system that we have in sympy, it nicely fits into the SymPy infrastructure. Ronan, if not into SymPy, where should TableForm go? 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.
