On Wed, Sep 18, 2013 at 3:46 PM, Peter Bruin <[email protected]> wrote:
>> Here's a concrete example: where should the generic implementation for
>> Euclid's operation live for computing e.[x]gcd(e)? It seems that it
>> makes the most sense to place this in the category rather than the
>> (many) element implementations (unless, of course, there are
>> compelling performance reasons).
>
>
> I would suggest that [x]gcd should be a method of the EuclideanDomainElement
> class (as it currently is).
Would any (non-dynamic) element class inherit from this?
> In the modified framework that I am thinking
> of, suppose the user constructs an instance R of the class Ring (or a
> subclass) that is a priori not Euclidean. Suppose also that R is detected
> to be Euclidean during construction (e.g. because R = PolynomialRing(A) and
> A happens to be a field) and placed in EuclideanDomains. Then, instead of
> making EuclideanDomains add its ElementMethods to R.element_class, I propose
> that the following should happen:
>
> R will be made an object in the category EuclideanDomains;
> EuclideanDomains has an attribute Object, which equals the class
> EuclideanDomain;
> therefore, EuclideanDomains has a dynamically generated object_class
> inheriting from EuclideanDomain;
> R will dynamically be made an instance of EuclideanDomains.object_class (by
> using EuclideanDomain as a base class or via some __getattr__());
> hence R will dynamically inherit from EuclideanDomain;
> furthermore, EuclideanDomain (being a subclass of Parent) has an attribute
> Element, which equals the class EuclideanDomainElement;
> therefore, R has a dynamically generated element_class inheriting from
> EuclideanDomainElement;
> R.element_class will dynamically be made to inherit from
> EuclideanDomain.element_class;
> hence R.element_class will dynamically inherit from EuclideanDomainElement,
> and have the correct gcd method.
>
> As you see, I am absolutely not trying to avoid the category framework; I
> think this approach uses it just as much as the existing one. The
> difference is that the category of Euclidean domains no longer directly
> specifies element behaviour, but does it via its object class, which I would
> find much more satisfactory. Assuming that something like the above would
> work, of course!
Basically, you want
class IntegralDomainElement(Element):
...
class IntegralDomain(Parent):
...
class EuclideanDomainElement(IntegralDomainElement):
def xgcd(self, other):
...
class EuclideanDomain(IntegralDomain):
Element = EuclideanDomainElement
class EuclideanDomains(IntegralDomains):
ParentMethods = EuclideanDomain
instead of
class EuclideanDomainElement:
def xgcd(self, other):
...
class EuclideanDomain:
...
class EuclideanDomains(IntegralDomains):
ElementMethods = EuclideanDomainElement
ParentMethods = EuclideanDomain
Is that a fair summary? One downside I see in this is redundancy (this
is a simple case, but if I want to insert PrincipalIdealDomains
between IntegralDomains and EuclideanDomains I have to hunt down
multiple places.) What's the value in letting EuclideanDomainElement
inherit from Element or IntegralDomainElement? I also see possible
issues here with multiple inheritance (e.g. the C struct
incompatibilities between RingElement and MatrixIntegerDense).
- Robert
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/groups/opt_out.
