On Mar 28, 2010, at 10:02 PM, Ondrej Certik wrote:
> On Sun, Mar 28, 2010 at 7:58 PM, Ronan Lamy <ronan.l...@gmail.com> wrote:
>> 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.
>
> Well, that's why I am importing simplify inside the method, so that
> the core doesn't depend on the rest.
>
> Ondrej
For what it's worth, I am +1 on adding these common functions as methods. It
is easier than ^Asimplify(^E), and the parentheses are nicer. Frankly, the
ability to do f(x).diff(x) is one of my favorite features of sympy.
Wasn't the point of splitting Basic so that we could put this bloating crap in
the one class and have only the essentials in the other? In other words, the
one level isn't so much at the "core" as the other.
Here's an interesting question: Matrix.simplify() simplifies in place. Should
Basic.simplify() do the same?
Also, that patch given needs a docstring.
Aaron Meurer
--
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.
