#14084: Wrong domain of the fraction field construction functor
------------------------------+---------------------------------------------
Reporter: SimonKing | Owner: roed
Type: defect | Status: needs_review
Priority: major | Milestone: sage-5.7
Component: padics | Resolution:
Keywords: | Work issues:
Report Upstream: N/A | Reviewers:
Authors: Simon King | Merged in:
Dependencies: | Stopgaps:
------------------------------+---------------------------------------------
Comment (by nthiery):
Replying to [comment:20 nbruin]:
> I think we really need another way to cache whether a ring is a field
then. What you describe is indeed the case:
> {{{
> sage: R=ZZ.quo(7)
> sage: R in IntegralDomains() ##1
> False
> sage: R in Fields()
> True
> sage: R in IntegralDomains() ##2
> True
> }}}
> you can see that the call `R in Fields()` has mutated the parent in an
essential way. The kind of call that people HAVE to use to look at the
category field because it is not trustworthy by itself even can change
depending on what happens with the parent elsewhere!
>
> Whether `##1` is a bug or not depends on how you interpret the question:
Are we asking the mathematical truth (which in general might be
undecidable) or are we asking what sage knows about the object by
construction? The first would of course be nicer, but computer algebra
systems often settle for the second.
By design, the category of an object in Sage describes:
(a) It's "operations" (additive structure, multiplicative
structure). This conditions what the morphisms are in the category.
(b) The properties of the operations that Sage is aware of at this
point in time (either because they were specified by the user or
discovered during some computation).
Note that the distinction between (a) and (b) will be made clearer
with the upcoming functorial construction patch #10963 which
introduces an infrastructure for "axioms" for (b).
I totally agree that (a) should not change over the lifetime of an
object. But I consider it a very important feature that (b) can change
over time: when we discover new properties of an object, we want to
exploit them to use better algorithms. And we might as well have every
reference to that object in the current Sage session benefit from the
improvement.
Of course, for that to make sense, changing (b) should only influence
efficiency, and not change the *semantic* of questions; for that the
questions should be unambiguous.
Note that GAP is doing (b) intensively for precisely that reason
(although they use a different mechanism, through method selection
rather than object orientation).
> By the way:
> {{{
> sage: R.category()
> Join of Category of commutative rings and Category of subquotients of
monoids and Category of quotients of semigroups and Category of finite
enumerated sets
> sage: R2.category()
> Join of Category of subquotients of monoids and Category of quotients of
semigroups and Category of finite fields
> }}}
> I have to say those values do a good job of dissuading people from ever
looking at them!
Working on that :-) With my current functorial patch, this should be
roughly "Category of finite commutative quotient fields."
Cheers,
Nicolas
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/14084#comment:24>
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?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
