Am 20.03.2012 15:24, schrieb Sergiu Ivanov:
> I'm trying to say
that I think that a group should be defined as an algebraic structure
with a single operation which has a number of properties; thus we may
define a class UniversalAlgebra, then derive Semigroup from it, then
Monoid, then Group. This would be similar to defining log as a
subclass of Function.
I have seen this kind of approach work excellently in Eiffel.
Unfortunately, it will run into trouble as soon as we need to inherit
the same algebraic data structure in two different roles.
For a handy example, Group cannot simply inherit from Monoid, since it
builds on two different monoids, the additive one (operator: +; neutral
element: Zero) and the multiplicative one (operator: *; neutral element:
One).
This can be circumvented: don't make Group inherit from Monoid twice,
make Group contain two Monoid members.
The question now is how to deal with those cases that could indeed be
done via inheritance (Monoid and Semigroup).
Alternative 1: Stick with inheritance. Might simplifiy some code (I have
no idea how much that would be in practice though).
Alternative 2: Make it a member, just for uniformity. Lowers the entry
barrier: new coders won't have to learn different coding patterns
depending on ancestry.
--
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.
