Sage: Ticket #1083: [with patch, with positive review] Bug in degree 1 number fields; manifests itself in element.matrix(), .trace(), .norm(), etc
https://trac.sagemath.org/ticket/1083
<p>
The following is not correct:
</p>
<pre class="wiki">sage: K.<a> = NumberField(ZZ['x'].0^2 + 2, 'a')
sage: L.<b> = K.extension(ZZ['x'].0 - a, 'b')
sage: L
Number Field in b with defining polynomial x - a over its base field
sage: L(a)
0
</pre><p>
This is the root of the following bugs:
</p>
<pre class="wiki">sage: a.trace(K)
sage: a.norm(K)
sage: a.matrix(K)
---------------------------------------------------------------------------
<type 'exceptions.TypeError'> Traceback (most recent call last)
... (snipped) ...
/Users/ncalexan/sage/local/lib/python2.5/site-packages/sage/rings/number_field/number_field.py in relativize(self, alpha, names)
2902 # self --> M that sends alpha to
2903 # the generator of the intermediate field.
-> 2904 from_M = M.hom([self.gen()], self, check=True)
2905 M._set_structure(from_M, to_M) # don't have to
2906 # worry about caching since relative number fields aren't cached.
/Users/ncalexan/Documents/School/MATH235/groebner/parent_gens.pyx in sage.structure.parent_gens.ParentWithGens.hom()
/Users/ncalexan/sage/local/lib/python2.5/site-packages/sage/rings/number_field/morphism.py in __call__(self, im_gen, base_hom, check)
172 if check:
173 im_gen = self.codomain()(im_gen)
--> 174 return self._from_im(im_gen, base_hom)
175
176 def _coerce_impl(self, x):
/Users/ncalexan/sage/local/lib/python2.5/site-packages/sage/rings/number_field/morphism.py in _from_im(self, im_gen, base_hom)
197 f = R([base_hom(x) for x in a.list()])
198 b = f(im_gen)
--> 199 abs_hom = K.hom([b])
200 return RelativeNumberFieldHomomorphism_from_abs(self, abs_hom)
201
/Users/ncalexan/Documents/School/MATH235/groebner/parent_gens.pyx in sage.structure.parent_gens.ParentWithGens.hom()
/Users/ncalexan/sage/local/lib/python2.5/site-packages/sage/rings/number_field/morphism.py in __call__(self, im_gens, check)
30 return self._coerce_impl(im_gens)
31 except TypeError:
---> 32 raise TypeError, "images do not define a valid homomorphism"
33
34 def _coerce_impl(self, x):
<type 'exceptions.TypeError'>: images do not define a valid homomorphism
</pre>en-usSagehttps://trac.sagemath.org/chrome/site/logo_sagemath_trac.png
https://trac.sagemath.org/ticket/1083
Trac 1.1.6ncalexanSat, 03 Nov 2007 20:09:13 GMT
https://trac.sagemath.org/ticket/1083#comment:1
https://trac.sagemath.org/ticket/1083#comment:1
<p>
Argh, that should be
</p>
<pre class="wiki">sage: K.<a> = NumberField(ZZ['x'].0^2 + 2, 'a')
sage: L.<b> = K.extension(ZZ['x'].0 - a, 'b')
sage: L
Number Field in b with defining polynomial x - a over its base field
sage: L(a)
0
</pre>
TicketmabshoffWed, 26 Dec 2007 02:50:42 GMTdescription, milestone changed
https://trac.sagemath.org/ticket/1083#comment:2
https://trac.sagemath.org/ticket/1083#comment:2
<ul>
<li><strong>description</strong>
modified (<a href="/ticket/1083?action=diff&version=2">diff</a>)
</li>
<li><strong>milestone</strong>
changed from <em>sage-2.10</em> to <em>sage-2.9.2</em>
</li>
</ul>
TicketcraigcitroMon, 21 Jan 2008 11:55:58 GMTstatus, owner, summary changed
https://trac.sagemath.org/ticket/1083#comment:3
https://trac.sagemath.org/ticket/1083#comment:3
<ul>
<li><strong>status</strong>
changed from <em>new</em> to <em>assigned</em>
</li>
<li><strong>owner</strong>
changed from <em>was</em> to <em>craigcitro</em>
</li>
<li><strong>summary</strong>
changed from <em>Bug in degree 0 number fields; manifests itself in element.matrix(), .trace(), .norm(), etc</em> to <em>[with bug report upstream (Pari)] Bug in degree 0 number fields; manifests itself in element.matrix(), .trace(), .norm(), etc</em>
</li>
</ul>
<p>
Man, this was a *bugger* to find. Here's the issue: at some point, we ask Pari to turn an absolute element into a relative element in a relative extension of degree n for us, and then we loop over the resulting polynomial from indices 0 to n-1 and add up some stuff. In the case that the relative extension is degree 1, Pari fails to do this correctly -- they don't reduce the polynomial below degree 1, which is what causes the trouble. The code proceeds to loop over just the 0th coefficient, which is just 0 in the example above.
</p>
<p>
Interestingly, the problem here only occurs when you try to *print* your element -- you can create the element just fine, it's only when you try and print it that this zeroing occurs. (This was why I had so much trouble finding it.)
</p>
<p>
I have a fix for this, but I've also reported the bug to the Pari folks -- given that this doesn't seem terribly pressing, if they're going to fix it upstream, it seems like just waiting would be the best approach. If I don't hear anything from them in a few days, I'll post a patch.
</p>
TicketcraigcitroTue, 22 Jan 2008 03:05:41 GMTsummary changed
https://trac.sagemath.org/ticket/1083#comment:4
https://trac.sagemath.org/ticket/1083#comment:4
<ul>
<li><strong>summary</strong>
changed from <em>[with bug report upstream (Pari)] Bug in degree 0 number fields; manifests itself in element.matrix(), .trace(), .norm(), etc</em> to <em>[with bug report upstream (Pari)] Bug in degree 1 number fields; manifests itself in element.matrix(), .trace(), .norm(), etc</em>
</li>
</ul>
<p>
I just looked at the title of this, and noticed the 0 should be a 1.
</p>
TicketncalexanTue, 22 Jan 2008 18:05:06 GMT
https://trac.sagemath.org/ticket/1083#comment:5
https://trac.sagemath.org/ticket/1083#comment:5
<p>
Good work, Craig Citro! I spent hours tracking it as far as I did, too -- it was a strange bug, that's for sure.
</p>
TicketcraigcitroWed, 23 Jan 2008 11:15:29 GMTattachment set
https://trac.sagemath.org/ticket/1083
https://trac.sagemath.org/ticket/1083
<ul>
<li><strong>attachment</strong>
set to <em>craigcitro-1083.patch</em>
</li>
</ul>
TicketcraigcitroWed, 23 Jan 2008 11:19:48 GMTsummary changed
https://trac.sagemath.org/ticket/1083#comment:6
https://trac.sagemath.org/ticket/1083#comment:6
<ul>
<li><strong>summary</strong>
changed from <em>[with bug report upstream (Pari)] Bug in degree 1 number fields; manifests itself in element.matrix(), .trace(), .norm(), etc</em> to <em>[with patch, needs review] Bug in degree 1 number fields; manifests itself in element.matrix(), .trace(), .norm(), etc</em>
</li>
</ul>
<p>
So I got a response from the pari team that the problem on their end is fixed in svn. However, given the fact that the Pari release cycle is slower than ours, I've added a workaround to Sage. Looking at the other tests Nick had above, I noticed that for any <a class="missing wiki">NumberFieldElement?</a> a, a.matrix(QQ) didn't work. I fixed this while I was there, and added a few doctests.
</p>
TicketncalexanSun, 27 Jan 2008 04:27:12 GMTsummary changed
https://trac.sagemath.org/ticket/1083#comment:7
https://trac.sagemath.org/ticket/1083#comment:7
<ul>
<li><strong>summary</strong>
changed from <em>[with patch, needs review] Bug in degree 1 number fields; manifests itself in element.matrix(), .trace(), .norm(), etc</em> to <em>[with patch, with positive review] Bug in degree 1 number fields; manifests itself in element.matrix(), .trace(), .norm(), etc</em>
</li>
</ul>
<p>
Apply! My only worry is that there is no reference, in the code, to the PARI bug, but maybe that is better?
</p>
TicketmabshoffSun, 27 Jan 2008 04:32:55 GMT
https://trac.sagemath.org/ticket/1083#comment:8
https://trac.sagemath.org/ticket/1083#comment:8
<p>
<a class="closed ticket" href="https://trac.sagemath.org/ticket/1891" title="task: remove workaround when Pari > 2.3.3 is released (closed: wontfix)">#1891</a> is the ticket to remove the work around once the fix is in upstream pari.
</p>
TicketmabshoffSun, 27 Jan 2008 05:14:26 GMTstatus changed; resolution set
https://trac.sagemath.org/ticket/1083#comment:9
https://trac.sagemath.org/ticket/1083#comment:9
<ul>
<li><strong>status</strong>
changed from <em>assigned</em> to <em>closed</em>
</li>
<li><strong>resolution</strong>
set to <em>fixed</em>
</li>
</ul>
<p>
Merged in Sage 2.10.1.rc1
</p>
Ticket