Le jeudi 28 avril 2011 à 19:17 -0700, Ondrej Certik a écrit : > On Thu, Apr 28, 2011 at 6:59 PM, Ronan Lamy <[email protected]> wrote: > > Le jeudi 28 avril 2011 à 17:43 -0700, Mateusz Paprocki a écrit : > >> Hi, > >> > >> On 28 April 2011 17:06, Ondrej Certik <[email protected]> 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. > But it's just a wrapper used but Mathematica's printing system. It only makes sense in relation with InputForm, OutputForm, StandardForm, MatrixForm, ...
> It might go into SciPy, but given all the printing system that we have > in sympy, it nicely fits into the SymPy infrastructure. > It certainly doesn't fit as a subclass of Basic. What's TableForm.args? TableForm.subs()? > Ronan, if not into SymPy, where should TableForm go? I'd say nowhere, because tablib[http://tablib.org] already exists. -- 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.
