Opened 8 years ago

Last modified 6 years ago

#17524 new defect

polynomial for relative number field elements

Reported by: Martin von Gagern Owned by:
Priority: minor Milestone: sage-6.5
Component: number fields Keywords:
Cc: Jakob Kroeker Merged in:
Authors: Reviewers:
Report Upstream: N/A Work issues:
Branch: Commit:
Dependencies: Stopgaps:

Status badges

Description

Consider the following field extensions:

sage: K.<z3, z4> = QQ.extension([x^2 + x + 1, x^2 + 1])
sage: z3 + z4 + z3*z4
(z4 + 1)*z3 + z4
sage: (z3 + z4 + z3*z4).polynomial()
-3*x^3 - 5*x^2 - 13*x - 7

This comes as a surprise. Relative number field elements share the documentation for that method with absolute number field elements, and that documentation simply reads:

Return the underlying polynomial corresponding to this number field element.

It is accompanied by an example which is using an absolute number field. According to that documentation, I'd expect (z4 + 1)*x + z4, since the field in z3 is the outer one and the one in z4 is the inner one. Instead, the element is apparently described as a polynomial in the power basis (z3 - z4). It took me quite a bit of reading source code (the _repr_ method in particular) to figure out that what I had expected is actually possible, but the method for this is called lift not polynomial.

I think that at the very least, the documentation of polynomial() should be extended and clarified, to document the behavior for nested number fields. If the behavior I observed is in fact intended. If not, it might make sense to make polynomial equivalent to lift in that case, and perhaps even deprecate the latter in the long run.

For some applications it might be even more useful if there were a method to recursively turn the element into a multivariate polynomial, with the number field generator names as variable names. But if you prefer, I can suggest that in a separate ticket, once the rest of this one here has been resolved.

Change History (3)

comment:1 Changed 8 years ago by Francis Clarke

I think the best strategy is that adopted for the norm of ideals in a relative number field:

sage: K.<z3,z4> = NumberField([x^2 + x + 1, x^2 + 1])
sage: I = K.ideal(3)
sage: I.relative_norm()
Fractional ideal (9)
sage: I.absolute_norm()
81
sage: I.relative_norm()
Fractional ideal (9)
sage: I.norm()
Traceback (most recent call last)
...
NotImplementedError: For a fractional ideal in a relative number field you must use relative_norm or absolute_norm as appropriate

Thus we could have relative_polynomial and absolute_polynomial, with polynomial leading to an error.

There are other methods for which this framework should be adopted in the interest of consistency. For example, for the norm of elements norm means the absolute norm. On the other hand minpoly is the relative version:

sage: z4.norm()
1
sage: z4.relative_norm()
-1
sage: z4.minpoly()
x - z4
sage: z4.absolute_minpoly()
x^2 + 1

while z4_absolute_norm is defined to be the same as norm() and z4_relative_minpoly gives rise to an AttributeError.

comment:2 Changed 8 years ago by Martin von Gagern

Having all these methods in two variations, absolute and relative, with otherwise equal names, makes a lot of sense to me.

Perhaps it would be better to to not throw a NotImplementedError but instead have two distinct classes for absolute and for relative number fields, both derived from a common base. That way a relative number field simply wouldn't have all those unqualified methods. That would make discovering available methods (e.g. using tab) more useful.

On the other hand, it would probably be good to have all these pairs of functions available for absolute number fields as well, as synonyms of the unqualified versions. That way one could write code which works for both absolute and relative number fields, without a need for case distinctions for these methods.

comment:3 Changed 6 years ago by Jakob Kroeker

Cc: Jakob Kroeker added
Note: See TracTickets for help on using tickets.