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.
