On 08/03/2008, Robert Bradshaw <[EMAIL PROTECTED]> wrote: > > On Mar 8, 2008, at 11:57 AM, John Cremona wrote: > > > > > Thanks, Robert -- I changed rings/integer_ring.pxd suitably and the > > build worked. > > > > Two things worry me about this: > > > > (1) Changing that caused a lot of recompilation with sage -b, > > suggesting that the file I changed is used a lot (not surprising). I > > just hope that this almost trivial change has not added unnecessary > > overhead in a lot of places. > > > No, it shouldn't have changed the overhead much, it's just that a lot > of things cimport this particular class. > > > > (2) In fact the EuclideanDomain class has essentially no > > functionality, so I wonder if it would not be better to remove it > > altogether, despite its place in the theoretical mathematical > > hierarchy of commutative rings. Think about it: the classical > > Euclidean rings ZZ and F[] (F a field) already have their perfectly > > good Euclidean implementation (division with remainder). I don't know > > if any other rings do. A few rings of integers are Euclidean, but it > > is highly nontrivial to say whether or not any individual one is, and > > Sage certainly does not try to do so, so the is_EuclideanDomain() > > function will return False except for specific rings (such as ZZ after > > the change I made), despite this being mathematically incorect. > > > > e.g. the Gaussian Integers: > > > > sage: GI = ZZ[sqrt(-1)] > > sage: GI > > Order in Number Field in I with defining polynomial x^2 + 1 > > sage: is_EuclideanDomain(GI) > > False > > > > Can anyone see a reason *not* to delete the is_EuclideanDomain() > > function and also the EuclideanDomain class? > > > is_EuclideanDomain should (and eventually will) be querying the > category, not the Parent's type. Trying to make the implementation > hierarchy follow the mathematical hierarchy is hard if not impossible > to do (especially without multiple inheritance). If something > declares itself to be in the category of euclidean domains, it will > automatically have, for example, a gcd function on elements. > > The EuclideanDomain class should probably go away (as will a lot of > others). I'm not sure how many errors it will introduce and/or how > hard it will be change. If it looks like it's going to be any > significant amount of work, I would recommend waiting until the > categories are more in place and doing the change then (rather than > having to touch all the code twice). >
I agree. I'm waiting! But the problem is at least logged as trac # 2430. John > > - Robert > > > > > > -- John Cremona --~--~---------~--~----~------------~-------~--~----~ 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/sage-devel URLs: http://www.sagemath.org -~----------~----~----~----~------~----~------~--~---
