Sage: Ticket #17524: polynomial for relative number field elements
https://trac.sagemath.org/ticket/17524
<p>
Consider the following field extensions:
</p>
<pre class="wiki">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
</pre><p>
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:
</p>
<pre class="wiki">Return the underlying polynomial corresponding to this number field element.
</pre><p>
It is accompanied by an example which is using an absolute number field. According to that documentation, I'd expect <code>(z4 + 1)*x + z4</code>, since the field in <code>z3</code> is the outer one and the one in <code>z4</code> is the inner one. Instead, the element is apparently described as a polynomial in the power basis <code>(z3 - z4)</code>. It took me quite a bit of reading source code (the <code>_repr_</code> method in particular) to figure out that what I had expected is actually possible, but the method for this is called <code>lift</code> not <code>polynomial</code>.
</p>
<p>
I think that at the very least, the documentation of <code>polynomial()</code> 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 <code>polynomial</code> equivalent to <code>lift</code> in that case, and perhaps even deprecate the latter in the long run.
</p>
<p>
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.
</p>
en-usSagehttps://trac.sagemath.org/chrome/site/logo_sagemath_trac.png
https://trac.sagemath.org/ticket/17524
Trac 1.2Francis ClarkeThu, 18 Dec 2014 15:58:23 GMT
https://trac.sagemath.org/ticket/17524#comment:1
https://trac.sagemath.org/ticket/17524#comment:1
<p>
I think the best strategy is that adopted for the norm of ideals in a relative number field:
</p>
<pre class="wiki">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
</pre><p>
Thus we could have <code>relative_polynomial</code> and <code>absolute_polynomial</code>, with <code>polynomial</code> leading to an error.
</p>
<p>
There are other methods for which this framework should be adopted in the interest of consistency. For example, for the norm of elements <code>norm</code> means the absolute norm. On the other hand <code>minpoly</code> is the relative version:
</p>
<pre class="wiki">sage: z4.norm()
1
sage: z4.relative_norm()
-1
sage: z4.minpoly()
x - z4
sage: z4.absolute_minpoly()
x^2 + 1
</pre><p>
while <code>z4_absolute_norm</code> is defined to be the same as norm() and <code>z4_relative_minpoly</code> gives rise to an <code>AttributeError</code>.
</p>
TicketMartin von GagernSat, 20 Dec 2014 16:28:04 GMT
https://trac.sagemath.org/ticket/17524#comment:2
https://trac.sagemath.org/ticket/17524#comment:2
<p>
Having all these methods in two variations, absolute and relative, with otherwise equal names, makes a lot of sense to me.
</p>
<p>
Perhaps it would be better to to not throw a <code>NotImplementedError</code> 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.
</p>
<p>
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.
</p>
TicketJakob KroekerSat, 04 Mar 2017 02:31:20 GMTcc set
https://trac.sagemath.org/ticket/17524#comment:3
https://trac.sagemath.org/ticket/17524#comment:3
<ul>
<li><strong>cc</strong>
<em>Jakob Kroeker</em> added
</li>
</ul>
Ticket