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: |
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
comment:2 Changed 8 years ago by
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
Cc: | Jakob Kroeker added |
---|
I think the best strategy is that adopted for the norm of ideals in a relative number field:
Thus we could have
relative_polynomial
andabsolute_polynomial
, withpolynomial
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 handminpoly
is the relative version:while
z4_absolute_norm
is defined to be the same as norm() andz4_relative_minpoly
gives rise to anAttributeError
.