On May 4, 2011, at 2:06 PM, Ronan Lamy wrote: > Le mercredi 04 mai 2011 à 20:09 +0200, Fredrik Johansson a écrit : >> On Tue, May 3, 2011 at 11:24 PM, Ronan Lamy <ronan.l...@gmail.com> wrote: >>> 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). >> >> I don't see how this is "more functional than object-oriented". On the >> contrary, using a class to encapsulate the notion of an algebra is >> more object-oriented than spreading the equivalent code across various >> methods in an ad-hoc fashion (for example, having Mul know about lots >> of different mathematical objects that can be multiplied) and choosing >> between options mostly by passing flags to functions. The code in Sage >> is quite clean, and very easy to extend (often easier than doing the >> same thing in SymPy). >> > Calling algebra.mul(a, b) instead of a.__mul__(b) is what I mean when I > say "more functional than object-oriented". Now, it's true that > Mul.flatten() is a cesspit of ugliness, but that's precisely because > __mul__ methods call Mul() instead of the other way round. > >> That's not to say SymPy should necessarily adopt an identical >> approach, but it's worth thinking about using explicit objects >> (whether they are called "algebras", "rings", "contexts", etc) to >> distinguish between different classes of mathematical objects and to >> store options. > > I'm not sure about options, but having explicit objects representing > mathematical types is certainly a good idea. The natural way of doing > that in Python is to use a class. > >> Whether singleton objects are used for special values like 1 is rather >> a trivial issue and completely orthogonal to other design >> considerations. AFAIK, the current design exists only for performance >> reasons ('is' is much faster than '==' in Python, but this is mostly >> irrelevant with C-based types, and it can be worked around fairly >> easily in Python anyhow). >> > Singleton objects are useful for more important things than optimising > '==' with 'is'. They represent 'sui generis' objects that have specific > behaviour. But that wasn't my point (not that you could have known it, > given that I forgot half the words in my final parenthesis). I meant > that having Integer(42) and Rational(42) being different, barely related > objects, is unintuitive and makes it hard to extend an existing > structure with additional objects. IIUC, to have something like > S.Infinity in Sage, you'd need to create a > TwoPointCompactifiedExtendedRealLine algebra and convert all your real > objects to it (granted, the last one seems to happen automagically).
+1. When I was working on the doctests in the polys, I was fixing some bugs in the domains, and I noticed that it's much cleaner to have QQ(2, 1) not automatically convert to ZZ(2). The SymPy domain required all kinds of special code to check for singletons and automatic casting like that, which would break if, for example, a new number was made into a singleton. Aaron Meurer -- 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.
