Le vendredi 26 mars 2010 à 23:58 -0700, Ondrej Certik a écrit : > On Fri, Mar 26, 2010 at 1:42 PM, Ronan Lamy <ronan.l...@gmail.com> wrote: > > Le jeudi 25 mars 2010 à 22:21 -0700, Ondrej Certik a écrit : > [...] > >> Yes, I would also define .simplify(), and maybe other methods in > >> Basic. Last time I sent the patch for this, it was opposed, that such > >> methods only make the Basic class (core) more complex. But I still > >> think that the most frequent methods (and simplify is one of them) > >> should be in the Basic. Also integrate. > >> > >> What do other think about this? > > > > That's quite exactly the opposite of what I've been trying to do. Having > > a big tangle of tightly coupled code is exactly what is preventing us > > from refactoring the core - and in particular, from replacing the > > assumption system. > > Here is the patch implementing .simplify(): > > > --- a/sympy/core/basic.py > +++ b/sympy/core/basic.py > @@ -2256,6 +2256,10 @@ def _eval_nseries(self, x, x0, n): > """ > raise NotImplementedError("(%s).nseries(%s, %s, %s)" % (self, x, x0, > n) > > + def simplify(self): > + from sympy import simplify > + return simplify(self) > + > def limit(self, x, xlim, direction='+'): > """ Compute limit x->xlim. > """ > > > and we already have .limit(), so I really think this does not make the > core any more complex.
I agree that it's not too bad (I thought you meant something more complex), but I'm still (weakly) against it since it introduces a dependency of the core on the rest of code. -- You received this message because you are subscribed to the Google Groups "sympy" group. To post to this group, send email to sy...@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.