#7643: composite_fields does not play nice with QuadraticFields
-----------------------------+----------------------------------------------
Reporter: rlm | Owner: davidloeffler
Type: defect | Status: needs_review
Priority: major | Milestone: sage-4.3.1
Component: number fields | Keywords:
Work_issues: | Author: Francis Clarke
Upstream: N/A | Reviewer:
Merged: |
-----------------------------+----------------------------------------------
Changes (by newvalueoldvalue):
* cc: ncalexan (added)
* status: new => needs_review
* author: => Francis Clarke
Comment:
When fields are constructed using `QuadraticField` they come with a
specified real or complex embedding. Then the problem is caused by the
following lines of `number_field.py` (which are only encountered when the
fields are both equipped with an embedding):
{{{
if r(embedding) > 1e-30: # XXX how to do this more
generally?
continue
}}}
In the case of the two quadratic fields, `r` is the polynomial `x^4 +
104*x^2 + 1764`, `embedding` is the element `4.619586622901255?*I` of
`Complex Lazy Field`, and `r(embedding)` is `0.?e-11`. Since this is
bigger than `1e-30`, the only compositum given by pari's `polcompositum`
is skipped and an empty list returned.
Worse still is the following example:
{{{
sage: C1.<a> = NumberField(x^3 - 2, embedding = CC(2^(1/3)))
sage: C2.<b> = NumberField(x^3 - 2, embedding = CC(2^(1/3)*exp(2*pi*I/3)))
sage: C1.composite_fields(C2)
[Number Field in ab0 with defining polynomial x^3 + 2]
}}}
Here `polcompositum` (which is independent of the embeddings) returns
{{{
[x^3 + 2, x^6 + 40*x^3 + 1372]
}}}
In the first case (which ought to be rejected since it is incompatible
with the given embeddings), `r(embedding)` is
`-18.0000000000000? + 31.1769145362398?*I` and `r(embedding) > 1e-30` is
`False` (sic!), so this field passes the test. In the second case (which
should be accepted), `r(embedding)` is `0.?e-11 + 0.?e-11*I` and
`r(embedding) > 1e-30` is `True`, so this field fails the test.
Clearly this test is not up to the job.
There is a simple way to rewrite the code, because when embeddings of both
fields are specified there is always only one compositum. Thus we can
simply pick the field for which `r(embedding)`takes a minimum value.
The patch implements this idea.
Another change is to only compute the maps into the composite when they
are required. In additiion various checks have been omitted, since pari
should have already done the necessary work.
I have also allowed the fields into which the two fields are embedded to
be different as long as they have a common ambient field, so that, for
example, the following now works:
{{{
sage: C1.<a> = NumberField(x^3 - 2, embedding = RR(2^(1/3)))
sage: C2.<b> = NumberField(x^3 - 2, embedding = CC(2^(1/3)*exp(2*pi*I/3)))
sage: C1.composite_fields(C2)
[Number Field in ab with defining polynomial x^6 + 40*x^3 + 1372]
}}}
Another problem with the present code is that when no embeddings are
specified it yields, in general, too many fields (because there are
duplicates). The following fields provide a good example: at present
{{{
sage: Q1.<a> = NumberField(x^4 + 10*x^2 + 1)
sage: Q2.<b> = NumberField(x^4 + 16*x^2 + 4)
sage: Q1.composite_fields(Q2)
[Number Field in ab0 with defining polynomial x^8 + 64*x^6 + 904*x^4 +
3840*x^2 + 3600,
Number Field in ab1 with defining polynomial x^8 + 160*x^6 + 6472*x^4 +
74880*x^2 + 1296]
}}}
`Q1` is the field `QQ(sqrt(-2), sqrt(-3))` and `Q2` is `QQ(sqrt(-3),
sqrt(-5))`. So there is only one compositum, i.e., `QQ(sqrt(-2),
sqrt(-3), sqrt(-5))`. The fields generated by the two degree 8
polynomials provided by `polcompositum` are isomorphic, and without
specifying the embeddings there is no way of distinguishing them.
`Q1.composite_fields(Q2, both_maps=True)` will choose embeddings of `Q1`
and `Q2` in the compositum, but there are four choices for each, none of
which is preferred.
The patch includes code which removes duplicates.
As a result of these changes, many changes have had to be made to the
doctests, which contained some misleading examples.
Also in the patch is code to deal with relative number fields, and, in the
case where a single field is returned, a minor change to the way that its
variable name is generated,
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/7643#comment:1>
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 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-trac?hl=en.
