On Tue, May 3, 2011 at 11:24 PM, Ronan Lamy <[email protected]> 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
>> > <[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 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).
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.
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).
Fredrik
--
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.
