Possible bug in UnitGroup

[Benjamin Matschke]

Dear all,

The following code raises a ValueError: [*some big element of L*] is not an S-unit.

L.<theta_L> = NumberField(x^6 - 68463*x^4 - 5120808*x^3 + 1250774892*x^2 + 192368273328*x + 7520491439712)
OLSstar = UnitGroup(L,proof=False,S=tuple(L.primes_above(2*5*7*13)))
u = OLSstar.gen(11)
print(u)              # yields u11
print(L(u))           # yields some very large element of L
print(OLSstar(L(u)))  # raises a ValueError

The last output should of course be u11 again. The above is the simplest example that I could extract. I have other examples, where the composed coersion from OLSstar to L and back to OLSstar is not the identity (according to sage, sometimes a minus is falsely introduced), although it should. I do not know where the error comes from.

Sometimes UnitGroup() also raises a PariError, which comes from bnfsunit() within UnitGroup.__init__(), which can be resolved by increasing pari's precision. The above error however persists after increasing pari's precision generously.

This was run on Sage 9.0, Linux Mint 19.3. Any help is appreciated.

Thanks,

Benjamin

[Justin C. Walker]

This isn’t an answer, but FWIW, I checked this on sage versions back to 8.3, and get the same result.

I also checked, on an older (“Yosemite”) system with sage 7.3, and that worked as you expect.

I don’t have time to dig into this, though.

HTH,

Justin

PS: All these were on Macs.

> --
> You received this message because you are subscribed to the Google Groups "sage-nt" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to sage-nt+u...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/sage-nt/276bbea0-ca70-411b-b2f9-f8ced377c7c2%40googlegroups.com.

--
Justin C. Walker
Curmudgeon at Large
Director
Institute for the Enhancement of the Director's Income
--
Build a man a fire and he'll be warm
for a night.
Set a man on fire and he'll be warm
for the rest of his life.

[Benjamin Matschke]

Thanks. The large S-unit generator is indeed produced by pari (but I'm not certain whether these are incorrect generators, or whether the initial bug comes from testing them for being S-units, and whether this also explains other inconsistencies between coecions between L and OLSstar and back in other examples):

L = bnfinit(x^6 - 68463*x^4 - 5120808*x^3 + 1250774892*x^2 + 192368273328*x + 7520491439712,1)

S2 = idealprimedec(L,2)
S2 = [S2[3],S2[2],S2[1]]
S7 = idealprimedec(L,7)
S13 = idealprimedec(L,13)
S13 = [S13[1],S13[3],S13[2]]
S5 = idealprimedec(L,5)
S = concat([S2,S7,S13,S5]) #The order matters, this one is compatible with sage's S = L.primes_above(2*5*7*13)

sfu = bnfsunit(L,S)

In GP 2.11.2 (via Sage 9.0), the last two generators in sfu are indeed very large.

In GP 2.9.4, it runs for a minute before raising a stack overflow.

Running the same example with a different order of input primes raises another bug (perhaps they are related):

S2 = idealprimedec(L,2)
S2 = [S2[3],S2[2],S2[1]]
S5 = idealprimedec(L,5)
S7 = idealprimedec(L,7)
S13 = idealprimedec(L,13)
S13 = [S13[1],S13[3],S13[2]]
S = concat([S2,S5,S7,S13]) #same order as what L.primes_above(2),...,L.primes_above(13) yields in sage.

sfu = bnfsunit(L,S)


In GP 2.11.2 (via Sage 9.0) this immediately raises an error:

  *** bnfsunit: impossible inverse in ZM_inv: [60, 40, 2, 0, 0, 0, 0, 54; 0, 20, 2, 0, 0, 0, 0, 0; 0, 0, 2, 0, 0, 0, 0, 0; 0, 0, 0, 6, 1, 2, 0, 0; 0, 0, 0, 0, 0, 6, 3, 0; 0, 0, 0, 0, 0, 0, 3, 0; 0, 0, 0, 0, 0, 0, 0, 42; 0, 0, 0, 0, 0, 0, 0, 0].

In GP 2.9.4 it again runs for a minute before raising a stack overflow.

Benjamin

On Friday, February 28, 2020 at 8:24:36 PM UTC-5, Justin Walker wrote:

This isn’t an answer, but FWIW, I checked this on sage versions back to 8.3, and get the same result.

I also checked, on an older (“Yosemite”) system with sage 7.3, and that worked as you expect.

I don’t have time to dig into this, though.

HTH,

Justin

PS: All these were on Macs.

> On Feb 27, 2020, at 23:02 , 'Benjamin Matschke' via sage-nt <sag...@googlegroups.com> wrote:
>
> Dear all,
>
> The following code raises a ValueError: [*some big element of L*] is not an S-unit.
>
> L.<theta_L> = NumberField(x^6 - 68463*x^4 - 5120808*x^3 + 1250774892*x^2 + 192368273328*x + 7520491439712)
> OLSstar = UnitGroup(L,proof=False,S=tuple(L.primes_above(2*5*7*13)))
> u = OLSstar.gen(11)
> print(u)              # yields u11
> print(L(u))           # yields some very large element of L
> print(OLSstar(L(u)))  # raises a ValueError
>
> The last output should of course be u11 again. The above is the simplest example that I could extract. I have other examples, where the composed coersion from OLSstar to L and back to OLSstar is not the identity (according to sage, sometimes a minus is falsely introduced), although it should. I do not know where the error comes from.
>
> Sometimes UnitGroup() also raises a PariError, which comes from bnfsunit() within UnitGroup.__init__(), which can be resolved by increasing pari's precision. The above error however persists after increasing pari's precision generously.
>
> This was run on Sage 9.0, Linux Mint 19.3. Any help is appreciated.
>
> Thanks,
> Benjamin
>
> --
> You received this message because you are subscribed to the Google Groups "sage-nt" group.

> To unsubscribe from this group and stop receiving emails from it, send an email to sag...@googlegroups.com.

[David Roe]

If you can reproduce the bug in the most recent version of pari, perhaps submitting a bug report to Pari would be good; they tend to be pretty responsive.

David

To unsubscribe from this group and stop receiving emails from it, send an email to sage-nt+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sage-nt/bea704f1-8822-4239-ba77-94728ce95ef3%40googlegroups.com.

[Benjamin Matschke]

Thanks, I did. For the reference: https://pari.math.u-bordeaux.fr/cgi-bin/bugreport.cgi?bug=2207

Benjamin

To view this discussion on the web visit https://groups.google.com/d/msgid/sage-nt/bea704f1-8822-4239-ba77-94728ce95ef3%40googlegroups.com.