re-fix doctest failures for 2.10.2.rc0 in sage/rings/number_field/

[craigcitro]

So the two doctests I "fixed" earlier weren't wrong -- they're dependent on the architecture, at least. Here are the issues, and then I'll say a short bit about what I understand wrt the actual problem:

• number_field.py:
  There's a doctest in here that takes an ideal, factors it, picks a uniformizer for
  each factor, and checks to see if the ideal generated by the uniformizer is equal
  to the original ideal. The issue is that the uniformizer we produce is different
  on different machines. I'm not sure if this is a wholly 32-bit vs. 64-bit issue,
  or something else. To be safe, I've removed the doctest, and replaced it with
  something much more innocuous.

  Someone much braver than I could put the doctest back, with the two possible
  results as # 32-bit and # 64-bit. I've fought long enough with this, though, that
  I just don't want to see it again -- I'm happy to be overruled on this. If so,
  the two doctest results should be:

  sage: [ Plist[i] == K.ideal(pilist[i]) for i in range(len(Plist)) ]
  [True, False, False] # 32-bit
  [True, False, True] # 64-bit
  

  It wouldn't be unreasonable to do this if it passes testall this way on the
  whole sage build farm, but my home machine and sage.math isn't enough data for
  me to commit to this doctest.

• number_field_ideal.py, line 868

  This one is stumping me but good. Looking at I.prime_factors() just calls
  I.factor() ... the difference pops up in the K.ideal(...) call. I know that
  the same input is getting passed there on both machines, but one (my machine)
  gets (w) back, and the other (sage.math) gets (-w) back. The problem isn't
  anywhere in the K.factor() method, though -- it's when you try to print the
  result that things go awry! Man, that's frustrating. So I've switched it for
  another doctest that doesn't cause trouble, because I know the goal is to get
  the release out the door. If someone wants to put it back, here's the original:

  sage: I = K.ideal(w*23**5)
  sage: I.prime_factors()
  [Fractional ideal (w)] # 32-bit
  [Fractional ideal (-w)] # 64-bit
  

Okay, so now for what little I understand about what's going on. The issue with the uniformizers is easier to believe, at least -- pari is producing different results for idealhnf(...) on the two architectures:

32-bit:

? K = nfinit(x^6+x^3+1) ; Kb = bnfinit(x^6+x^3+1) ;
? P = idealfactor(K,idealhnf(K,17))[1,]
%2 = [[17, [1, 0, -7, 0, 1, 0]~, 1, 2, [1, 7, 6, 1, -3, 0]~], 1]
? bnfisprincipal(Kb,idealhnf(K,P))
%3 = [[]~, [-1, 1, -1, -1, -1, 1]~]
? Kb.zk
%4 = [1, x^3, x, x^4 + x, x^2, x^5 + x^2]
? idealhnf(K,P)
%5 = 
[17 0 8 2 6 15]

[0 17 6 8 8 6]

[0 0 1 0 0 0]

[0 0 0 1 0 0]

[0 0 0 0 1 0]

[0 0 0 0 0 1]

64-bit:

? K = nfinit(x^6+x^3+1) ; Kb = bnfinit(x^6+x^3+1) ;
? P = idealfactor(K,idealhnf(K,17))[1,]
%2 = [[17, [1, 0, -7, 0, 1, 0]~, 1, 2, [-6, 7, 6, 1, -3, 0]~], 1]
? bnfisprincipal(Kb,idealhnf(K,P))
%3 = [[]~, [1, -2, -1, 0, 1, 2]~]
? Kb.zk
%4 = [1, x^3 + 1, x, x^4 + x, x^2, x^5]
? idealhnf(K,P)
%5 = 
[17 0 2 11 15 11]

[0 17 6 8 8 15]

[0 0 1 0 0 0]

[0 0 0 1 0 0]

[0 0 0 0 1 0]

[0 0 0 0 0 1]

I don't know enough about what's happening inside to know what's making it get one result or the other, but the point is that for uniformizers, that difference is the first one that pops up, and it tracks through all the way to ending up with different uniformizers.

Now, for the other problem -- with -w vs. w -- I believe, but I'm not 100% sure, that pari's hnf causes the 1 vs. -1 issue. I know William just got a patch from Karim Belabas to fix exactly this kind of thing, but I'm not completely sure where the difference is cropping up to see if it's the same thing happening. Maybe the patch "over-corrects"?

I'm off to sleep now, but I'll nose around first thing in the morning to see if I can do anything else.

Component: number theory

Issue created by migration from https://trac.sagemath.org/ticket/2257

[JohnCremona]

comment:1

Attachment: trac-2257.patch.gz

I agree entirely with the above analysis, except that I don't think it's a 32/64 problem (my machine is 32 bit but gave the generator -w).

I give the patch a positive review now so 2.10.2 can hit the streets. For the future, doctest writers should remember to be careful when there's more than one mathematically correct output and algorithms are not always deterministic.

[sagetrac-mabshoff]

comment:2

Merged in Sage 2.10.2.final