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.
In general of course I agree with you that we should keep the core as
simple as possible. But my argument is that those simple methods like
.limit() or .simplify() or .integrate() just make it more convenient
for the user to find the right method. So I am still +1 for adding
those 3 line long methods.
Ondrej
--
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.
