#15192: add is_unit() for residue fields
-------------------------------------------+----------------------------
Reporter: saraedum | Owner:
Type: enhancement | Status: needs_review
Priority: trivial | Milestone: sage-6.0
Component: categories | Resolution:
Keywords: | Merged in:
Authors: Julian Rueth | Reviewers:
Report Upstream: N/A | Work issues:
Branch: u/saraedum/ticket/15192 | Commit:
Dependencies: | Stopgaps:
-------------------------------------------+----------------------------
Comment (by pbruin):
Replying to [comment:6 saraedum]:
> > Finite field elements should be made to inherit from field elements!
> I agree. I wonder if there is a reason why they don't?
Probably because they also derive from `IntegerMod` (for prime fields) and
`FinitePolyExtElement`, respectively; I assume one could use multiple
inheritance, but it might be tricky. However, this should certainly be
fixed.
> In any case, should `Ring` really define `is_unit`?
(I assume you mean `RingElement`...)
> Isn't the idea that elements figure these things out depending on their
parent, i.e., whether they are a unit depends on the parent.
That is clear; talking about elements doesn't even make much sense without
mentioning parent sets. But there isn't really any 'figuring out' to be
done here: if the element knows that it is a field element, then it knows
that being a unit is equivalent to being non-zero. An element can either
know that is is a field element because it inherits from `FieldElement`,
or otherwise (e.g. if the parent can only determine at runtime if it is a
field) using the `is_field()` method of the parent.
> Putting this into the category framework seems to be the right thing.
I don't agree, for the same reason why I wrote the comment at
http://trac.sagemath.org/ticket/13441#comment:20. Parents describe
relations between elements; e.g. a ring is a set whose elements satisfy
certain axioms. Categories are on a higher level; they describe relations
between objects, and it shouldn't matter too much what the elements of
these objects are, or even if the objects are sets at all.
Whether an element is unit depends on relations satisfied ''within'' its
parent, not on relations between the parent and ''other'' parents. In
other words, the category its parent is in should not play any role. It
is true that some categories (like the category of rings) ''are'' in a
sense defined by relations between the ''elements'' of objects, but
exploiting this to influence the behaviour of elements is confusing two
different levels of abstraction, in my opinion.
Hence, I don't see a good mathematical reason for putting methods in
`Ring.ElementMethods` instead of `RingElement`. I can see why one would
want a `Category` to have `ObjectMethods` (which are now called
`ParentMethods`) and perhaps `MorphismMethods` (which only exist in a
doctest). With `ElementMethods`, however, I somehow get the feeling that
the authors of the category framework are aiming for world domination!
> (Notice that `is_unit` was already there for `Fields()`).
Yes, but `FieldElement` still has its own `is_unit()`. I would expect
that `RingElement` should have one, too, and that these are the correct
locations for these methods, rather than `*.ElementMethods`.
> So is there any benefit of such an implementation in `Ring`? Don't all
rings live in the category of `Rings()` now?
Maybe, but I don't think this is a good argument for using the category
framework here. I think the benefit of putting ring element methods in
`RingElement` is that it simply seems the most logical place.
Sorry for the long sermon; this might have been more appropriate for a
sage-devel discussion...
--
Ticket URL: <http://trac.sagemath.org/ticket/15192#comment:7>
Sage <http://www.sagemath.org>
Sage: Creating a Viable Open Source Alternative to Magma, Maple, Mathematica,
and MATLAB
--
You received this message because you are subscribed to the Google Groups
"sage-trac" 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-trac.
For more options, visit https://groups.google.com/groups/opt_out.
