On Tue, May 3, 2011 at 2:02 PM, Tom Bachmann <e_mc...@web.de> wrote:
> On 03.05.2011 21:47, Ondrej Certik wrote:
>>
>> On Tue, May 3, 2011 at 8:44 AM, Fredrik Johansson
>> <fredrik.johans...@gmail.com>  wrote:
>>>
>>> On Tue, May 3, 2011 at 3:00 PM, Tom Bachmann<e_mc...@web.de>  wrote:
>>>>
>>>> Actually how does this relate to the following wiki page:
>>>>
>>>> https://github.com/sympy/sympy/wiki/Algebras-in-SymPyCore
>>>
>>> It's roughly the same thing.
>>
>> I also think that what Fredrik says might be a good idea. I don't have
>> much experience with this to have a clear opinion though. The reason I
>> have just used Add/Mul/Pow classes for everything in SymPy (long time
>> ago) is that it is conceptually a super simple idea, and it got us
>> very far. E.g. from the Zen of Python:
>>
>> 1) Simple is better than complex (Add/Mul/Pow is simpler than all the
>> algebras+other machinery)
>> 2) Complex is better than complicated (the algebras are probably
>> better than the complicated entangled assumptions+cache)
>>
>>
>> As such, I now that we can get very fast just with Add/Mul/Pow (see
>> the csympy code: https://github.com/certik/csympy), and when using
>> Refine() and other things, we should be able to have core not using
>> assumptions nor cache, be fast, and using the new assumptions in
>> refine(). That fixes the current sympy, using pretty much the same
>> architecture.
>>
>
> I don't find that a very convincing argument (which is not saying you are
> wrong, of course). Given a specific problem everyone (given enough time,
> energy, and general cleverness) can come up with a nice and clean solution
> that is also fast. The problem with comparing this to current sympy is that
> current sympy does *a lot* more. E.g. all of the core classes (Mul, Pow etc)
> treat orders, non-commutative symbols, etc etc. Now you may rightly argue

Please list the "etc., etc.":

* Non-commutative symbols should not be handled by the core. And if
they do, it's easy to create an NCMul class, as it used to be long
time ago in sympy.

* orders: don't understand this point, why it should cause any problems

> that this should not be in core, but I suppose you do not want to throw it
> away either...

The noncommutative symbols not assumptions are used a lot, except in
special cases here and there in tests. Those tests should be made to
pass obviously, but we should not be constrained by the fact, that we
"can't throw away old assumptions". Christian's branch showed that
indeed that is possible.

Ondrej

-- 
You received this message because you are subscribed to the Google Groups 
"sympy" group.
To post to this group, send email to sympy@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.

Reply via email to