31 views

Skip to first unread message

Feb 28, 2020, 4:43:11 PM2/28/20

to sage-nt

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

Feb 28, 2020, 8:24:36 PM2/28/20

to sag...@googlegroups.com

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.

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.

Mar 1, 2020, 7:15:42 PM3/1/20

to sage-nt

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

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.

Mar 1, 2020, 8:04:03 PM3/1/20

to sag...@googlegroups.com

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.

Mar 1, 2020, 8:36:08 PM3/1/20

to sage-nt

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.

Reply all

Reply to author

Forward

0 new messages

Search

Clear search

Close search

Google apps

Main menu