[with patch, needs a substantial amount of work] weird bug creating fractional ideal in relative number field

This might well be fixed by the patches posted for #1946. Unfortunately I do not seem to be able to test that, owing to my complete incompetence in applying patches, even my own. It would be a good idea if #1946 was cross-referenced to this one.

In case this seems crazy: fixing #1946 by adding lots of doctests to the code for Tate's algorithm over number fields revealed some minor bugs in its implementation, and fixing those revealed some bugs in the code for ideals and fractional ideals in number fields. I fixed that (in late January, partly jointly with William) and at the same time -- I seem to remember -- fixed this thing about ideals in relative extensions.

Both the patches attached to #1946 are waiting review....

This is still broken in sage-3.0.

The problem is triggered at line 89 of number_field_ideal_rel.py (in 3.0.5):

            gens = [ L(R(x.lift().lift())) for x in gens ]

In the case above , L is the field K and (when x is gens[1]) R(x.lift().lift()) is the polynomial (-b + 1)*x - b - 2 over the base field of K. But the real difficulty is that NumberFieldElement.__init__ doesn't work properly for relative fields; it ought to coerce a polynomial over the base field into the field, but doesn't.

Rather than trying to resolve the general problem with this coercion, it's easy to rewrite the above line 89, as in the attached patch. Then the following works:

sage: K.<a, b> = NumberField([x^2 + 1, x^2 + 2])
sage: A = K.absolute_field('z')
sage: from_A, to_A = A.structure()
sage: abs_ideals = [f[0] for f in A.factor(3)]
sage: rel_ideals = [K.ideal([from_A(y) for y in I.gens()]) for I in abs_ideals]
sage: rel_ideals
[Fractional ideal (3, a - 1), Fractional ideal (3, (-1)*a - 1)]
sage: prod(rel_ideals)
Fractional ideal (3)
sage: [J.is_principal() for J in rel_ideals]
[True, True]

Hi Francis,

I changed the title slightly so our various sql queries pick it up.

Cheers,

Michael

Hi,

Two things. First, the patch needs at least one doctest.

Second, something very fishy is going on. After applying this patch, I try out the example at the top of the definition of NumberFieldFractionalIdeal_rel, under the WARNING:

sage: K.<a> = NumberField([x^2 + 1, x^2 + 2]); K
Number Field in a0 with defining polynomial x^2 + 1 over its base field
sage: i = K.ideal([a+1])
sage: i
Fractional ideal (1)

If a+1 generates the unit ideal, it had better be a unit. But a+1 is really 1+i (the Gaussian integer), which is not a unit. Alternatively

sage: (a+1).norm()
4

which is not +1 or -1.

Continuing the calculation, we have

sage: i.gens()
(a + 1,)
sage: i.gens_reduced()
(1,)

and i.__repr__() via i._repr_short(self) uses i.gens_reduced()

The problem is with lines 90–92 of number_field_ideal_rel.py

            ## Make sure that gens[1] is in L, not K
            Lcoeff = [ L(x) for x in list(gens[1].polynomial()) ]
            gens[1] = S.hom([L.gen()])(S(Lcoeff))

which seem totally wrong-headed. In the case in question gens is [2, (-b)*a] (which is ok). Then (-b)*a gets converted to 1/2*x^2 + 3/2, which is the polynomial representing it in the absolute field, after which x is (in a most convoluted way) replaced by a, giving (of course) 1 (which is not ok).

There must be a much simpler way to achieve the object of ensuring that the generator is an element of the relative field.

Oh look, the patch is probably fine, but I go completely nuts every time I delve into any of the algebraic number theory stuff in Sage. I mean, why on earth is NumberFieldFractionalIdeal a subclass of Ideal_generic?? That's completely nuts. ***A fractional ideal is not an ideal.*** That's about as sensible as making Rational a subclass of Integer. Trying to patch this one line at a time is like trying to stop global warming with a toothpick.

I suggest that you (1) report the above as a separate ticket, (2) add a doctest to your patch to at least illustrate the corrected behaviour, (3) "correct" the doctest under the WARNING so at least it doesn't fail when doctests are run, (4) do a full run of doctests to see what else "breaks", (5) replace "Willia Stein" by "William Stein" in the authors at the top of the file, and (6) find someone else game enough to review this patch.

I spent several evening 6 months ago on this chunk of code, trying to see how it was supposed to work and fixing what didn't. It was not a very happy experience -- not helped by the fact that this was just about the first ever Sage development which I did. On the other hand, I was helped a lot at the time by William. Th eonly reason I got into that code at all was that I decided to add doctests to ell_number_field.py and found lots of things broken.

Anyway, while I cannot guarantee to have time to review this properly soon, I'll do what I can.

The more I look at number_field_ideal_rel.py, the more I notice needs doing. For example, in

    def absolute_ideal(self):
        """
        If this is an ideal in the extension L/K, return the ideal with
        the same generators in the absolute field L/Q.
        """
        try:
            return self.__absolute_ideal
        except AttributeError:
            rnf = self.number_field().pari_rnf()
            L = self.number_field().absolute_field('a')
            R = L['x']
            nf = L.pari_nf()
            genlist = [L(R(x.polynomial())) for x in list(self.gens())]
            self.__absolute_ideal = L.ideal(genlist)
            return self.__absolute_ideal

(1) The generator of the absolute field is always called 'a'; it would be much better if the user could choose the name, and, even better, was also able to get the absolute ideal via something like A = K.absolute_field('z'); A(J). (2) Neither rnf nor nf get used. (3) Since x.polynomial() is a rational polynomial, L(R(x.polynomial())) is the same as L(x.polynomial()). (4) In this context, list(self.gens())is no different from self.gens().

I've come to the conclusion that a more serious rewrite (with some more testing doctests) is needed, for which I'm unlikely to have much time in the next few weeks. My one-line patch was really only meant to point out where the defect lay.

I have made a new ticket #3680 to cover my general gripes about the algebraic number theory framework. But I don't have time to work on it now.