Ah OK, thanks. A brief look at the file makes me think it could be worked around by having a common base class NumberRingElement that can have most of the common functionality (but does NOT inherit from FieldElement) which can then be subclassed for number field elements etc. Whether maximal order elements need their own subclass will become apparent when executed. It's quite a project due to the size of the file but in principle not a super complicated refactoring. Number ring elements get used all over the place, so loads of potential for complications... For now I'll just work around it by giving the subclass its own routine, returning NotImplemented to signal the feature isn't available. Hopefully this is one the only place where elements of an integral domain that is not a field inherit from FieldElement anyway.
On Monday, 28 April 2025 at 09:09:29 UTC-7 dmo...@deductivepress.ca wrote: > > The inheritance from FieldElement has caused problems for a long time, and > I would welcome a fix. (See issue #12242 > <https://github.com/sagemath/sage/issues/12242> from 2011 for example.) > Please open an issue. It seems to me that the relation between OK and K > should be similar to the relation between ZZ and QQ, so there shouldn't be > any need for elements of OK to inherit from FieldElement. > > On Sunday, April 27, 2025 at 11:06:03 PM UTC-4 Nils Bruin wrote: > >> I ran into the following problem for elements of rings of integers: they >> inherit from FieldElement. That's a problem when, for instance you want to >> implement a method "canonical_associate" that tries to find a canonical >> representative modulo multiplication by units. For fields, such a thing is >> easily defined, but for rings of integers such a method isn't necessarily >> easy to implement. It's natural to implement this method on "FieldElement", >> but then elements of rings of integers inherit that method (and it does the >> wrong thing there!) >> >> I'd be interested if someone has a coherent idea about how we can handle >> such issues. It seems to me we have a problem in our inheritance hierarchy. >> I suspect someone made this design decision (that superficially looks like >> an error) for a good reason and may have put some thought into how to >> easily work around the obvious draw-backs. >> >> The following mro illustrates the problem: >> >> sage: R.<x>=ZZ[] >> sage: K.<a>=NumberField(x^3+x+1) >> sage: OK=K.ring_of_integers() >> sage: type(OK.0).mro() >> [<class >> 'sage.rings.number_field.number_field_element.OrderElement_absolute'>, >> <class >> 'sage.rings.number_field.number_field_element.NumberFieldElement_absolute'>, >> <class >> 'sage.rings.number_field.number_field_element.NumberFieldElement'>, >> <class >> 'sage.rings.number_field.number_field_element_base.NumberFieldElement_base'>, >> <class 'sage.structure.element.FieldElement'>, >> <class 'sage.structure.element.CommutativeRingElement'>, >> <class 'sage.structure.element.RingElement'>, >> <class 'sage.structure.element.ModuleElement'>, >> <class 'sage.structure.element.Element'>, >> <class 'sage.structure.sage_object.SageObject'>, >> <class 'object'>] >> >> -- 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 sage-devel+unsubscr...@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/sage-devel/f6a1ffea-2892-48b8-9bf1-db202594232en%40googlegroups.com.
