#11670: fix number fields being unique parents -- this got broken over the years
-------------------------------------+-------------------------------------
Reporter: was | Owner: davidloeffler
Type: defect | Status: needs_review
Priority: major | Milestone: sage-6.2
Component: number fields | Resolution:
Keywords: | Merged in:
Authors: Julian Rueth | Reviewers: Simon King
Report Upstream: N/A | Work issues:
Branch: | Commit:
u/saraedum/ticket/11670 | 70702aa690a31cc36b9febe36462c67ebd57dcee
Dependencies: | Stopgaps:
-------------------------------------+-------------------------------------
Comment (by pbruin):
I see what you mean. Maybe one could try to formalise the notion of
"unique parents" more precisely as follows.
We have some Python callable `NumberField()` that takes as input some key
(defining datum) `d` and outputs some Python object `K` depending on `d`
and representing a number field. This `NumberField()` uses (implicitly)
some algorithm, say `same(d, e)`, that given two keys `d` and `e` decides
whether `d` and `e` define the same number field. (The meaning of "the
same" is a bit vague; one could either use a mathematical definition
involving extra structure on the number field, or one could take "the
same" to mean by definition that `same(d, e)` returns True.)
Of course, `same` should behave like an equivalence relation (`same(d, d)
== True`, `same(d, e) == same(e, d)`, and transitivity holds). I think
that "`K` and `L` were created using the same arguments" should be
interpreted as `K` and `L` being names assigned to the objects returned by
`NumberField(d)` and `NumberField(e)` for some `d` and `e` for which
`same(d, e)` is True. I'm not sure if we have to assume any implication
between `same(d, e)` and `d == e`; it is possible that `same(d, e)` is
actually implemented as `d == e`.
Now consider the following boolean-valued statements about possible keys
`d` and `e`:
1. `d is e`
2. `same(d, e)`
3. `NumberField(d) is NumberField(e)`
4. `NumberField(d) == NumberField(e)`
Clearly, the implications 1 => 2 and 3 => 4 are automatic, and 2 => 4
probably holds already. It seems that saying "number fields are unique
parents" is the same as saying that the implementation of `NumberField()`
ensures that the implications 2 => 3 (hence 2 => 4) and 4 => 3 both hold,
and maybe even 3 => 2.
If I understand correctly, this ticket makes sure that 2 => 3 holds, but
not necessarily 4 => 3. From that perspective it makes sense to have a
separate ticket to implement the "other half" of the unique parents
property.
--
Ticket URL: <http://trac.sagemath.org/ticket/11670#comment:31>
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/d/optout.
