Le mardi 03 mai 2011 à 22:02 +0100, Tom Bachmann a écrit : > 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 that this should not be in core, but I suppose > you do not want to throw it away either... > > This is why I think the algebras approach is better: there different > algebras can manage expressions of different complexity. So lots of > things that are in current core and slow us down can just become part of > more specialised algebras. Note also that csympy would/could then become > the "core" algebra, achieving a final synthesis of approaches.
I don't understand that argument. You could just as well say, with sympy's current design, that different expressions can be implemented by different classes, etc. The big issue I see with these algebras is that it creates a design that's more functional than object-oriented and destroys the identity of objects that belong to several structures (e.g. in Sage, Integer(1) are different objects). > Obviously, it's hard to discuss merits without a proper writeup. The > idea of "several algebras" (Fredrik+Pearu) is new to me. I have been > meditating it quite a bit today, and I hope I can come up with something > coherent to discuss tomorrow morning. > > > Fredrik+Pearu's approach might be a better approach, looking at things > > from a different angle, as Fredrik says, it might not be that > > difficult to use. I still think though, that we should first get > > assumptions out of the core, and then we can either just use csympy, > > or we can switch to Fredrik+Pearu's approach. > > > > 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.
