Thanks, I did. For the reference: https://pari.math.u-bordeaux.fr/cgi-bin/bugreport.cgi?bug=2207
Benjamin On Sunday, March 1, 2020 at 8:04:03 PM UTC-5, David Roe wrote: > > If you can reproduce the bug in the most recent version of pari, perhaps > submitting a bug report > <https://pari.math.u-bordeaux.fr/Bugs/Reporting.html> to Pari would be > good; they tend to be pretty responsive. > David > > On Sun, Mar 1, 2020 at 7:15 PM 'Benjamin Matschke' via sage-nt < > [email protected] <javascript:>> wrote: > >> 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 < >>> [email protected]> 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 [email protected]. >>> > 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. >>> >>> >>> >>> -- >> 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 [email protected] <javascript:>. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/sage-nt/bea704f1-8822-4239-ba77-94728ce95ef3%40googlegroups.com >> >> <https://groups.google.com/d/msgid/sage-nt/bea704f1-8822-4239-ba77-94728ce95ef3%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> > -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/sage-nt/0748ea13-96cc-421a-9038-1da439b30ac5%40googlegroups.com.
