On May 3, 2011, at 6:30 PM, Ondrej Certik wrote: > On Tue, May 3, 2011 at 2:02 PM, Tom Bachmann <[email protected]> wrote: >> On 03.05.2011 21:47, Ondrej Certik wrote: >>> >>> On Tue, May 3, 2011 at 8:44 AM, Fredrik Johansson >>> <[email protected]> wrote: >>>> >>>> On Tue, May 3, 2011 at 3:00 PM, Tom Bachmann<[email protected]> 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
This is probably the same sort of thing that we worked on in Los Alamos. The core should be rewritten so that it doesn't specifically know about things that combine into other things, like Order, infinity, etc. See http://code.google.com/p/sympy/issues/detail?id=1941. I'm also +1 on removing non-commutativity from the core. How should we do it. Should we just have an NCMul class whose first argument is a Mul (or Atom), which would be the non-commutative part? Aaron Meurer > >> 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. > > Ondřej > -- You received this message because you are subscribed to the Google Groups "sympy" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/sympy?hl=en.
